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E magazinnal együtt a rendezvényre érvényes belépő- 


jegyet minden előfizetőnkhöz eljuttattuk. 
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Egyévesek lettünk, sőt, már el is múltunk. Pont 
egy évvel ezelőtt, 2000 szeptemberében jelent 
meg lapunk első száma. Az elmúlt egy évben 
igen sok mindenről szó esett lapunk hasábjain, s 
mindig megpróbáltuk tartani magunkat az ere- 
deti koncepcióhoz: valami olyasmit adjunk, ami máshol nem ér- 
hető el. Olyan olvasmányokat adjunk közre, melyek ha néha a 
kissé szabadabb stílus, szóhasználat miatt könnyednek tűnnek 
is (hisz magunk között vagyunk, megtehetjük :-) tartalmukban 
sűrűek. Sűrűek, és - amennyire csak ez lehetséges - hibátla- 
nok, mi több, objektívek! Az objektivitás megőrzése kívülről ta- 
lán nem tűnik egyszerű feladatnak, ha az ember a Microsoft Ma- 
gyarország Szakmai Magazinjába ír, de szerencsénkre egy olyan 
Microsoft Magyarország áll a hátunk mögött, mely felismerte, 
hogy sokkal nagyobb, hosszú távú haszon rejlik egy-egy kényel- 
metlen, de őszinte kijelentésben, mint amennyit a tények csű- 
rése-csavarása hoz. Ha egyáltalán hoz, és nem visz. Ez a straté- 
gia állított olvasóink táborába nem egy hithű junikszost is - 
akik így legalább belülről ismerik meg az ellenséget. 

A folyamatos, lelkes munkát egész évben végigkísérte a ha- 
táridők folyamatos lecsúszása. Küzdünk ellene teljes akara- 
tunkból, de sajnos mindig kiderül, hogy egy informatikai 
lap készítése is informatikai munka, azaz érvényes rá a né- 
gyes szorzó paradoxona. Az vesse ránk az első követ, aki 
rendszergazdaként, vagy méginkább programozóként vala- 
ha az életben is sikeresen megbecsülte volna egy projekt 
hosszát. A szorzóparadoxon miatt ugyanis ha helyesen be- 
csülte fel, az értéket meg kell szoroznia néggyel, tehát nem 
helyesen becsülte fel. (Agytorna: a sevillai borbély azokat 
borotválja, akik nem maguk borotválkoznak. Ővele mi lesz?) 





Mit kapunk szülinapunkra? 

Mint minden ünnepelt, mi is kaptunk meglepetéseket. Itt van 
mindjárt a címlapon lévő torta. Más ajándékra is fájt a fo- 
gunk, s meg is kaptuk olvasói visszajelzések formájában. A 
szeptemberi, kanálhajlítós szám valami elképesztő sikert ara- 
tott mind a külcsínt, mind a belbecset illetően. Köszönjük! 
Hálánk jeléül egyes előfizetőinknek hibásan írtuk fel a címlap- 
ra a Memóriakzelés szót, hogy példányuk még értékesebbé 
váljon. Mint egy hibásan fogazott bélyeg: aranyat ér! 


Mit adunk? 

Az európai kultúrkörben nem szokás ugyan, hogy az ünnepelt vi- 
szonozza az ajándékokat, mi mégis így teszünk. Azt szeretnénk, 
hogy minden kedves előfizetőnk érezze: mi egy csapat vagyunk, 
a közös cél a magyar informatikusok élvonalban tartása. 


MesterOrzus 

Az év folyamán született meg a MesterOrzus ötlete, mely egyfaj- 
ta író-olvasó találkozó, és agytorna. A MesterOrzust azért vezet- 
tük be, hogy az esetleg nehezebben átadható-leírnató mondani- 
valónak is helyet biztosítsunk. Én magam is érzékeltem, hogy a 
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szó, mely ugyan elszáll, mennyit segít bizonyos témakörök fel- 
dolgozásában! A minden hónap utolsó péntekén tartott 
MesterOrzusok igen látogatott eseményekké nőtték ki magukat! 


Mikulás 

Tavaly decemberben jött el hozzánk először a Mikulás, akit 
ablakba rakott, kisuvickolt NetAcademia bögrével várt az a 
százhúsz olvasónk, aki eljött az akkori rendezvényre. Mivel 
nem vártak hiába, az a gyanúnk, hogy idén is eljön! Tegyék 
szabaddá magukat december ötödikén, hátha a Mikulás ér- 
tékeli szorgalmukat, hogy még azon a napon is Kerberost 
hallgatnak, VBScriptet írnak, LDAP-pal bütykölnek stb. Mi- 
kulásrendezvényünk lesz az első alkalom, hogy kipróbáljuk 
az interaktív konferenciázást. Érezd a Kerberost! 


NATE 

Ez a vonat már elment, de jövő februárban megint indul a 
NetAcademia Továbbképzési Estek előadássorozat, ahol egy 
adott témakört több héten át boncolgatva alapos hozzáértést 
lehet szerezni. A csütörtök délutánonkénti bitfúrás-bitfaragás 
témaköreit kibővítjük. Marad a Win2k, de bejön a képbe még 
egy-két olyan téma, ahol a közös reszelés mindenkinek (írónak, 
olvasónak) előnyére válik. Ilyen lesz (bízvást) az SOL alkalma- 
zásfejlesztés, (talán) a security (Hacking is easy!) és egyebek. 


Könyvkukac 

Az MSDEV listán merült fel először az igény, hogy olyanok is hoz- 
zájuthassanak méregdrága (tizenötezer forintos, sőt drágább!) 
könyvekhez, akik ezek megvásárlására nem rendelkeznek megfe- 
lelő anyagi háttérrel /értelmes főnökkel. Az ötletre azonnal lecsap- 
tam, és már készül is a Napster csereberéléséhez hasonló elven 
működő könyvkukac web, ahol nemcsak kölcsönözni, hanem fel- 
kínálni is lehet majd köteteket. Csak és kizárólag előfizetőknek! 


Msdownload.netacademia.net 

Az msdownload szintén az Önöké, de nem mi adjuk, hanem 
a Microsoft Magyarország. Mi csak a kivitelezők és fenntar- 
tók vagyunk. Mostantól nem kell külföldről letöltögetni a 
javítócsomagokat, ingyenes programokat és hasonló jószá- 
gokat. Kereshető, magyarnyelvű leírásokat tartalmazó adat- 
bázis, tíz gigabájtnyi adat, száz megabites hálózat - ez a 
http://msdownload.netacademia. net! 


Jövőkép 

S hogy mit hoz a jövő? A táguló világegyetem magával húz- 
za, egyre tágítja az informatikát is. Lassan rájövünk, mi min- 
denre jó az Internet, elszaporodnak a .NET alkalmazások, s mi 
megint kezdhetjük elölről a tanulást. Stílszerűen kifejezve: 
SOAP-ás. De nem tartom fel Önöket tovább: olvassanak! 


Fóti Marcell 
marcellfonetacademia.net 
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Ntbackup.exe 


Windows 2000-rel 


A Windows NT és a Windows 2000 beépített mentőszoftvere 
az NTBackup, minden feltelepített verzióban elérhető, s az 
ntbackup.exe-vel indítható. A Windows NT 4.0 óta sokat vál- 
tozott, és a Windows 2000-ben a már majdnem teljesen töké- 
letes ntbackup.exe-t találhatjuk. Sajnos azonban korántsem 
tökéletes, néhány gyermekbetegség még mindig felfedezhető 
rajta, és sok esetben az is észrevehető, hogy ami a Windows 
NT 4.0 alatt futó Backup programban egyértelmű volt, az 
hiányzik a Windows 2000 Backup-ból. Ennek oka nyilvánvaló: 
az egész programot átírták, nem maradt a régiből egy bit sem. 


Microsoft Windows Backup. 


SEB) Vason50 
5 1999 VERITAS Software Corporation. Allrights reserved. 
Click onthe URL below to go lo VERITAS Soltwares web site 


VEBITAS Software Corporation 


9 Az új NTBackup nem is Microsoft fejlesztés! 


Mi inspirált a cikk megírására? Elsősorban az, hogy az 
ntbackup.exe és a Removable Media Storage (későbbiekben 
RMS) párossal igencsak meggyűlt a bajom, mire működésre 
bírtam, illetve a környezetemben, és a Windows 2000 leve- 
lezési listán is azt tapasztaltam, hogy mások számára sem 
volt egyértelmű ez a technológia. Másodsorban pedig az 
hajtott, hogy nem akartam elhinni, hogy a Microsoft (majd- 
nem) tökéletes operációs rendszerében található beépített 
eszköz nem működőképes. 

Cikkem során szeretnék túllépni a termékpáros (ntbackup-RMS) 
egyszerű bemutatásán. Megpróbálok mentési szisztémát aján- 
lani, illetve néhány elvárást támasztani a következő verziójú 
ntbackup.exe-vel szemben - hátha megfogadják Redmondban :). 
A program neve Windows NT, és Windows 2000 alatt is 
ntbackup.exe (hiszen a Windows 2000 is NT), pedig, mint 
említettem, a két változat korántsem egyforma. Előfordul 
olyan is, amikor sűrűn váltogatva ntbackup.exe-ként hivat- 
kozom a Windows NT 4.0 és a Windows 2000 változatára. 
Ilyenkor mindig kiírom előtte, hogy melyikről írok. 


Az ntbackup.exe régen és ma 

A Windows NT 4.0-ban levő ntbackup.exe a maga nemében 
tökéletes volt, hisz tökéletesen működött, azonban a korral 
haladva fejlesztése elkerülhetetlenné vált. Vállalati környe- 
zetben nem elegendő az, hogy manuálisan tökéletesen tu- 
dunk menteni. Szükségünk van arra is, hogy off-line időpon- 
tokban, felügyelet nélkül tudjunk teljes mentést végezni. A 
Windows NT 4.0-ban található ntbackup.exe erre úgy adott 
lehetőséget, hogy saját készítésű mentési scriptet/scripte- 
ket kellett készíteni; ebben a verzióban beépített időzítési 
lehetőség még nincs, az új verzióban már ez is megtalálha- 
tó. Nagyvállalati környezetben elengedhetetlen, hogy 
könnyedén tudjunk távoli erőforrásokat menteni. A régi ver- 
zióban erre szintén nincs közvetlen támogatás, azonban az 
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új már ezt is magában hordozza. A harmadik nagy újdonság 
pedig az, ami az egész programot megváltoztatta és talán a 
legtöbb problémát okozza a rendszergazdák számára: a ka- 
zetta formátuma. A Windows NT 4.0 ntbackup.exe-je minden 
kazettára hajlandó volt menteni, amit csak a szalagos egy- 
ségbe betettünk, a Windows 2000 esetében ez már egy ki- 
csit másképp működik. A kazettákért (media) az RMS a fele- 
lős és megmondhatjuk, hogy mikor melyik kazettára ment- 
hetünk. Ezzel elkerülhető, hogy egy fontos mentést felülír- 
junk egy új mentési feladattal (bővebben később). 

Még egy újdonságot meg kell, hogy említsek. Az új 
ntbackup.exe-vel már fájlba is készíthető mentés, és arról 
bármikor elvégezhető visszatöltés. Így akár kisebb rendsze- 
rekről is készíthető mentés anélkül, hogy szükséges lenne 
drága mentési egységek beszerzése. Természetesen tovább- 
ra is ajánlott megfelelő mentési egység beszerzése. 

Fontos újdonság, hogy míg a Windows NT 4.0 esetén a 
mentési egységen (szalagon) katalógusinformáció is helyet 
kapott, addig erre már nincs szükség az új ntbackup.exe 
esetén. Miért jó ez? Aki már állított vissza NT 4.0 mentés- 
ből az tudja, hogy a Catalog Status az egyik legfontosabb 
és a legkritikusabb része a visszaállításnak. Sajnos, ha a Ca- 
talog megsérül akkor nem lehet a mentést visszaállítani. 
Windows 2000 esetén nincs szükség a Catalog-ra így az el- 
veszett mentések száma is csökken. 


Távoli erőforrások mentése 

Beszéltünk már arról, hogy a Windows 2000 ntbakup.exe-vel 
könnyedén lementhető bármely távoli erőforrás. Egyszerűen 
csak az ntbackup.exe-ben tallózva kiválasztjuk a mentendő 
erőforrást. NT 4.0 esetében is megoldható volt a távoli men- 
tés: fel kellett csatlakoztatni (MAP) a kívánt erőforrást és utá- 
na már le lehetett menteni. Ennek oka az volt, hogy - mint az 
intézőben tallózva - csak a betűjellel ellátott meghajtókat 
tudtuk lementeni, a régi NTBackup nem ismerte az UNC útvo- 
nalakat (1 Ikiszolg megoszt). Ennek a módszernek óriási hát- 
ránya, hogy mivel nem UNC path-tal lettek lementve az ada- 
tok, mind a visszaállítás, mind a dokumentálás nehézkesebb. 
Egy tavaly júliusban lementett I: meghajtó kevésbé , beszé- 
des", mint pl. a Nsrvo1Yd$VexchsrvrVogs útvonal. 

A Windows 2000 Backup-ban végre UNC Path segítségével 
is könnyedén menthetünk. 


Beépített időzítő segíti a munkánkat... 

...használatával a mentéseket jobokként kezelhetjük és 
minden jobnak megmondhatjuk, hogy mikor futhat, mennyi 
a maximális futási idő, kinek a nevében stb. Ezen újdonsá- 
gok csak egy része újdonság valójában. A Windows NT 4.0-t 
telepítve is volt lehetőségünk programok, saját készítésű 
parancsfájlok, így mentések időzített indítására. Az at pa- 
rancsot használva beidőzíthettünk parancsokat, a parancs- 
futtató felhasználót is beállíthattuk - ugyan nem parancson- 
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WINDows 2000 





WINDows 2000 NTBACKUP.EXE WINDOWS 
ként, de amennyiben a Scheduler szolgáltatás tulajdonsá- 
gainál a Service Account nevét megváltoztattuk, az at-vel 
időzített parancs is a megadott felhasználó nevében, annak 
jogosultságaival futott le. Internet Explorer 5.0 telepítése 
esetén új szolgáltatás települ a Windows NT 4.0-ra is: a Task 
Scheduler (természetesen, akár ki is hagyható a telepítése, de 
az alapértelmezett telepítés frissíti a rendszert). A Windows 
2000 alapértelmezésben tartalmazza ezt az új szolgáltatást. 
Alapvetően nem változott sokat az at-hez képest, viszont 
sok új többletszolgáltatást hordoz magában: 

"8 jobonkénti service account megadásának lehetőségét 
"0 maximális futási időt 

"8 kényelmes grafikus kezelhetőséget 

Ezek nagyon fontos tulajdonságok, s a Windows 2000 
Backup az új időzítő (Task Scheduler) minden plusz szolgál- 
tatását tökéletesen kihasználja. 

Egy mentési job elkészítésekor (vagy utólag is) megadhat- 
juk a futási környezetet. Beállíthatjuk, hogy mi legyen fu- 
táskor használt kezdőkönyvtár, mikor fusson, milyen rekur- 
ziót használjon, mekkora legyen a futás maximális időtar- 
tama, mi legyen a mentéskor használt felhasználó neve és 
jelszava. Az ntbackup.exe-ben egy naptárban ábrázolva lát- 
hatjuk, hogy mikor milyen mentési job fog futni. 


Sajnos ha egy jobot adminisztrálunk, bármit módosítunk 
azon, jóváhagyáskor - amennyiben előzőleg megadtuk - 
a rendszer kéri tőlünk a felhasználónév/jelszó párost. Ez 
minden módosításra érvényes. Elég bosszantó funkció, 
de meg lehet kerülni: amennyiben a felugró ablakban a 
Cancel gombot választjuk, a job emlékezni fog az előző- 
leg megadott információra és megőrzi működőképessé- 
gét. (Jalos: köszönöm) 
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0 Naptárnézet az ntbackup.exe-ben 


Nem kell a katalógusinformáció... 

. ..mert a Windows 2000 a Windows NT 4.0-hoz képest teljesen 
másképp kezeli a kazettákat, médiumokat. A Windows NT 
NTBackup.exe minden használatkor a kazettáról olvasta le a ka- 
talógusinformációt, amit a használat után (az ntbackup.exe be- 
zárása után) törölt, majd a kazetta ismételt használatakor is- 
mételten leolvasta, ha tudta. (A Temp könyvtárban hozta létre 
101 végződéssel ezeket a fájlokat.) A ravasz rendszergazda még 
az ntbackup.exe bezárása előtt lemásolta ezeket az eredeti he- 
lyükről egy másik könyvtárba. Ekkor megmaradt a katalógusin- 
formációnk teljes értékű mentése. 
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Windows 2000-ben a kazettákért és minden más médiáért a 
Removable Media Storage (RMS) felelős. Az RMS elsődleges 
feladata, hogy a médiák (Médiumok? Ehh! Ki tudja ezt ragoz- 
ni? -— a szerk.) és az alkalmazások közötti , fordító" szerepet 
betöltse. Az RMS a médiákat úgy nevezett Media Pool-okba 
szervezi. Ezekben elvileg minden media megtalálható, amit 
a gépünkön használtunk; a médiákat GUID alapján különíti 
el egymástól. A media pooloknak két fő verziója létezik: 
8 System media pool: ezt csak az RMS használhatja, más 
alkalmazás nem módosíthatja. Az alkalmazások hozzáfér- 
hetnek a Free System Media Pool-hoz, az abban levő mé- 
diákat a saját Application media pool-jukba mozgathatják. 
"8 Application media pool: az alkalmazások kezelik a poolo- 
kat, az alkalmazások az általuk használni kívánt mediá- 
kat a Free System media pool-ból veszik át. Egy gépen 
akár több Application media pool is lehet, amit akár az 
alkalmazás is létrehozhat, de természetesen kézzel is 
elkészíthetők a megfelelő pool-ok a Microsoft Manage- 
ment Console Removable Media Storage konzolból. 
Az ntbackup.exe automatikusan, első indításkor létrehozza 
a Backup nevű Application Pool-t. Az alkalmazás (ntbackup.exe) 
bezárását követően az RMS megtartja, lementi a kazettához 
vagy más médiához tartozó katalógusállapotot. A média is- 
mételt használatakor, már a berakást követően az RMS a 
GUID alapján a médiát felismeri és tudja, hogy mi találha- 
tó az egységen. Ez ugye egyben azt is jelenti, hogy ha egy 
média off-line állapotban van, az RMS akkor is tud a médiá- 
ról mindent. Tudja azt is, hogy a média épp off-line álla- 
potban van. Miért is jó ez? Annak, hogy az RMS beépült a 
média és az alkalmazás közé, az a gyakorlati haszna, hogy 
míg eddig az ntbackup.exe (Windows NT 4.0 alatt) az egy- 
ségben levő bármely médiához korlátlanul hozzáfért, addig 
Windows 2000 alatt az ntbackup.exe csak és kizárólag az 
Application Pool alatt található médiához fér hozzá: oda 
importálhat médiát. Ennek következménye az is, hogy egy 
mentési job elkészítésekor megmondhatom azt, hogy me- 
lyik médiára menthet és ezzel kizárom annak lehetőségét, 
hogy egy korábbi mentésemet felülírjam a jelenlegivel. Az 
RMS a médiák intelligens kezelését biztosítja. 
Az RMS elérhető a Computer Managenet Snap-in - ből vagy a 
Microsoft Management Console Removable Media Storage 
Snap-in hozzáadásával. Megnyitás után láthatjuk a System 
Media Pool-okat (Free, Import és Unrecognizable) és az App- 
lication Media Pool-okat (köztük a Backup Pool). Minden 
System Media Pool alatt megtalálható a mentési egység. Az 
én gépemben egy 4mm DAT egység található, de ha több esz- 
közöm lenne, mindegyik megtalálható lenne a Poolok alatt. 
Az RMS segítségével a Poolok között a médiákat mozgathat- 
juk. Az alkalmazás csak az alkalmazás Pool-ban levő médiát 
használhatja (az NTBackup csak a Backup Poolban lévőt) , vagy 
a Free System Poolból a saját Pooljába mozgathat egy üreset. 
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Cíáre más 








5 Removable Media Storage (RMS) 


CD író és a Windows 2000 RMS 

A CD írók használatával kapcsolatban meg kell jegyeznem 
egy hasznos, fontos információt, mielőtt még többen ne- 
kiesnének az írónak, a TechNet-nek és az MS Supportnak. 
A Windows 2000 ntbackup.exe nem képes közvetlenül 
mentést készíteni a CD-R, CD-RW és DVD-R típusú lemezek- 
re, eszközökre. Ennek gyakorlatilag elég egyszerű oka van: 
a Free System Media Pool alá nem tudjuk mozgatni a nyers, 
üres lemezeinket. Ennek hátterében az áll, hogy az RMS a 
Free Media Pool-ba csak a felismerhető fájlrendszert tartal- 
mazó adathordozót képes mozgatni. Ez sajnálatos módon 
a by design kategóriába tartozik, vagyis a Microsoft ezt így 
tervezte, ez nem hiba. A CD író programok használata el- 
kerülhetetlen, legalább a lemez formázására. 

Azonban jó hír, hogy az október 25-én debütáló Windows 
XP már képes lesz a CD-R, CD-RW, DVD-R lemezek natív ke- 
zelésére. Sajnos a Windows XP-t futtató gépemben (még) 
nincs CD író eszköz, de hamarosan tesztelni fogom ezt a 
funkciót is, az eredményt az újságban közzétesszük. 


Ntbackup.exe és a parancssor 

A Windows 2000 ntbackup.exe-nek 18 parancssori kapcso- 
lója létezik. A parancssori kapcsolók teljes leírása, ismer- 
tetése megtalálható a Help-ben (az ntbackup /? Parancs 
beírásával megjelenik) . 

A Windows 2000 Backup bks kiterjesztésű fájlt használ a 
mentendő útvonalak eltárolására. A bks fájl text formátum- 
ban külön sorokba felsorolva tartalmazza a mentendő ada- 
tokat. A szintaktikája annyira egyszerű, hogy nincs is igazi 
szintaktikája. Egyszerűen fel kell csak sorolni külön sorokba 
szeretnénk menteni, akkor a sor végére a /Exclude szöveget 
kell megadnunk. A következő pár sor egy bks fájl részlete, 
ami meghatározza, hogy a C:(CmdCons, a C: Wocs könyvtá- 
rakat lementjük, de a C: DocsWTemp könyvtárat nem: 


c: VCmdcons 
c:Wocs 
c:WocsiTemp /Exclude 


A parancssori kapcsolók közül kiemelném a Windows NT 4.0- 
hoz képesti újdonságokat: /T a kazetta neve; /N név az új ka- 
zettának; /D címke a mentésnek; /UM az első elérhető sza- 
bad kazettára ment; /P a media pool nevét határozza meg. 
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A tökéletes és automatikus mentés beállításához a követ- 

kező lépéseket kell elvégezni: 

"8 Bekell helyezni a mentésre kijelölt szalagot a meghajtó- 
ba, és egy kisebb mennyiségű adatot az ntbackup.exe- 
vel menteni kell. Erre azért van szükség, hogy az MTF 
(Microsoft Tape Format) a kazettára megfelelően felke- 
rüljön. Ezzel egyidőben az Application Media Pool-ba 
vándorol a kazetta, így azt az NTBackup a későbbiek- 
ben is használni tudja majd. 

"5 Az előző lépést minden használni kívánt kazettával el 
kell végeznünk. Érdemes mentés közben beszédes cím- 
kéket és leírásokat használni a kazettákhoz. Erre jó 
példa a mentési napok és a mentési típusok keveréke 
pl.: Monday Full Backup. 
Létre kell hozni az NTBackup.exe segítségével a menté- 
si jobokat úgy, hogy miután megadtuk a mentendő 
adatokat, ki kell választanunk, hogy hová szeretnénk 
menteni. Ekkor a legördülő mezőben láthatjuk az elő- 
zőleg elkészített kazettákat és azok közül valamelyiket 
válasszuk ki. Vigyázat: ezzel azt érjük el, hogy arra és 
csak arra a kazettára, fog menteni az NTBackup.exe! 

"8 Amennyiben mentési ciklusunkba új kazettát szeretnénk 
utólagosan felvenni, ismét helyezzük be a kazettát, 
mentsünk rá valami minimális adatot, majd a szüksé- 
ges jobokat módosítsuk. 


Tippek: 

Az RMS a kazettákat GUID, és nem a nevük alapján különböz- 
teti meg egymástól. A GUID-ok megtekintésére kiváló eszköz 
a Windows 2000 Resource Kitben található rsm. dbutil.exe. 
Sajnos alapértelmezésben a bks fájlok a User ProfilWser 
NamelXocal SettingsV4Application DatalWindows o NTY 
NtBackup elérési út alatt jönnek létre. Természetesen elmá- 
solható erről a helyről, de utána kézzel ki kell javítani a 
job(ok)-ban a hivatkozási útvonalat. 

A Backup log a User ProfillUser Namelocal SettingsN 
Application DatatWindows NTWtBackup elérési út alatt jön 
létre. Ezt nem tudjuk módosítani. Ez bizony nagy-nagy hiba! 
Az NTBackup.exe nem futtatható Interactive módban, ami 
azt jelenti, hogy nem tudja bármely bejelentkező felhaszná- 
ló felügyelni a futást. Az ntbackup.exe programot csak az 
látja a képernyőm, akinek a nevében fut. (A Windows NT 4.0- 
ban megszokott Interactive kapcsoló egyszerűen hiányzik. 
Sajnos a Windows XP-ben a hiba szintén megtalálható. ) 

Az ntbackup.exe az /um kapcsolóval (UnManagement) fut- 
tatva az első szabad médiára ment. 


Mentési stratégiák 

Mikor beszélhetünk jó mentésről? Jó és sikeres mentés az, ami- 
kor a rendszer helyreállíthatóságához, és a felhasználók szem- 
pontjából minden hasznos és fontos adatot sikerül lemente- 
nünk. De elegendő-e csupán az, ha az adatokat le tudtuk men- 
teni? Nyilván nem elegendő, hiszen ezeket helyre is kell tud- 
nunk állítani. A jó és sikeres mentés kivitelezése elég összetett 
feladat. Rendszertervezésekor mentési stratégiát is kell készíte- 
nünk. A stratégiánknak tartalmaznia kell a következőket: 

8 Mit kell lementenünk, azoknak mekkora mérete? 

"8 Milyen gyakorisággal kell mentenünk az adatokat? 

- Ki felügyeli a mentések helyességét? 

"8 Hány kazetta, hány egység áll rendelkezésünkre? 
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Mentési stratégiánkat úgy kell elkészíteni, hogy a rendelke- 
zésünkre álló eszközöket és a mentési igényeket össze kell 
hangolnunk. Szerencsésebb eset, amikor csak az igények 
vannak meg, és a szakember a mentési stratégiát kidolgoz- 
va az ahhoz szükséges összes eszközt megkapja. A fenti 
adatok elengedhetetlenül fontosak a jó mentési stratégia 
meghatározásához és elkészítéséhez. 

Meg kell határoznunk, hogy mik azok az adatok amiket men- 
tenünk kell. A rendszer helyreállíthatóságával kapcsolatban 
is nehéz megmondani, hogy mit kell mentenünk, de általá- 
nosságban elmondható, hogy a SystemState mentése mindig 
ajánlott. A felhasználói adatok mentését mindig a rendszer 
sajátosságai határozzák meg számunkra. Meg kell keresni 
azokat a személyeket, akik ezeket a kérdéseket eldönteni hi- 
vatottak. Ezek után meg kell nézni a mentendő adatok tény- 
leges méretét, azokat egy próbamentéssel ellenőrizni. Min- 
den esetben ajánlott 1099-kal feljebb kalkulálni a mentést, 
mert amennyiben HOME könyvtárakat mentünk, előfordulhat, 
hogy a megnövekedett adatmennyiség már nem fér rá az 
egységre. A mentés során a kazetták archiválására és azok új- 
rahasznosítására is gondolnunk kell. Ez szintén függ az adott 
rendszer felépítésétől. Gondolni kell arra is, hogy hány nap- 
ra visszamenőleg szeretnénk megőrizni a mentéseket. A tö- 
kéletes mentési stratégia kidolgozásához elengedhetetlenül 
fontos ismernünk a mentési típusokat, azok előnyeit, hátrá- 
nyait; néhány példát is megnézünk ezekkel kapcsolatban. 


Eltérő mentési típusok 

A Windows 2000-ben ötféle mentési típus közül választhatunk: 

"8 Normal (Teljes mentés; FULL): a kijelölt fájlok és könyv- 
tárak mindig mentendők. Minden újabb mentéskor újra 
mentődnek. Visszaállítása egyszerű és gyors, mert ele- 
gendő a legutolsó helyes mentést előkeresni és azt 
visszaállítani. Használata során azonban sok kazettára 
van szükség, ha több napra visszamenőleg is szeretnénk 
a mentéseket megőrizni. Viszont egy-egy kazetta fe- 
lülírása nem befolyásolja a visszaállíthatóságot. Az 
utolsó helyes kazettáról az adatok visszaállíthatóak. 

"8 Incremental: csak az utolsó normal vagy Incremental men- 
tés óta módosult fájlok jelölődnek meg mentendő ada- 
tokként. Használata során az utolsó sikeres normal 
mentés kazettájára és az összes inkrementális szalagra 
is szükségünk van. 

"8 Differential: csak az utolsó normal mentés óta módosult 
adatok mentődnek le. 

"8 Copy: minden mentéskor minden adat lemásolódik. A fáj- 
lok archive attribútuma nem változik. 

"0 Daily Copy: az adott napon módosult adatokat menti le. 
A fájlok archive attribútuma nem változik. 

Az öt különböző mentési típust a megfelelő mentési straté- 

gia eléréséhez kombinálva vagy akár önmagában is felhasz- 

nálhatjuk. A leggyakoribb mentési stratégiákat bemutatom. 

Elkészítettem egy szemléltető ábrát is, ami jelöli a menten- 

dő adatokat a különböző mentési típusoknál. 
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Mentett adatok Különböző mentési típusok 
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Péntek hétfő kedd szerda csütörtök 
II Flt Backup 
I Full váth Dífferentiat 


5 Különböző mentési típusok 


1 
ci 


Full with Incrementat 


Normal Backup (Teljes mentés): 

Ezt a stratégiát használva minden nap minden adatot le- 
mentünk. Ennek a mentési stratégiának a hátrányai a követ- 
kezők: a mentési idő viszonylag hosszú (mert minden nap 
mindent le kell menteni); minden napra egy ugyanakkora ka- 
zettára van szükségünk, mert a mentendő adat mindig azo- 
nos (természetesen ha nem változik; 99-ban értendő) Előnye: 
amennyiben vissza kell állítanunk az adatokat, elegendő az 
utolsó sikeres mentéshez használt kazetta adatát visszaálli- 
tani. Archiválás esetén elegendő egy kazetta archiválása. 


Normal with Incremental (Teljes növekményes mentés): 

Ezt a stratégiát használva teljes mentés készül pénteken ahogy 
az az előző ábrán is látható. Ezt követően hétfőn lementődik 
minden ami módosult péntek óta, kedden lementődik minden 
ami módosult hétfő óta, és így tovább, pénteken pedig ismét 
egy teljes mentés készül. Ha mondjuk a keddi állapotot kell 
visszaállítanunk, ahhoz szükségünk van az utolsó teljes men- 
tés kazettájára, és az azóta készült összes inkrementális kazet- 
tára is. Ha bármely kazetta sérül, nem lehet visszaállítani a 
mentést. Előnye: a teljes mentés után az inkrementális men- 
tések ideje lényegesen kisebb mint a teljes mentésé, s kisebb 
helyet is foglal. Az archiváláshoz el kell rakni egy egész cik- 
lust, így lényegesen több kazettára van szükségünk. 


Normal with Differential (Teljes különbségi mentés) 

Ezt a stratégiát használva teljes mentés készül pénteken, majd 
hétfőn a péntek óda módosult adatok mentődnek, kedden szin- 
tén a péntek óta módosult adatok, stb. Ennek köszönhetően a 
mentendő adatok mennyisége - ahogy haladunk előre az időben 
- növekszik. (lsd: ábra) Amennyiben a szerdai állapotot kell 
visszaállítani, elegendő az utolsó teljes mentés (péntek) és a 
szerdai kazetta. Hátránya: minden nap tovább tart a mentés és 
egyre több adatot kell lementeni. Amennyiben archiválni szeret- 
nénk bizonyos állapotot, legalább két kazettát el kell raknunk. 


Nehéz feladat... 

. ..a Windows 2000 és az RMS használata, valamint a megfele- 
lő mentési stratégia megállapítása, de nem lehetetlen. Meg- 
próbáltam a lehető legtöbb információt besűríteni a cikkembe, 
de természetesen van néhány információ ami kimaradt. Ha 
maradtak megválaszolatlan kérdések a kedves olvasóban, a 
Tech.Net levelezési listára, vagy közvetlenül nekem küldje el. 


Harmath Zoltán 


zoliogeniusgroup.hu 
MCSE, MCPai 
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Recovery 
onsole 


A Windows 2000 csökkentett módú (safe-mode) és Recove- 
ry Console rendszerindítási változatai több lehetőséget biz- 
tosítanak az el nem induló számítógép helyreállításához. A 
csökkentett mód lehetővé teszi, hogy a számítógép a mű- 
ködéshez minimálisan szükséges eszközmeghajtók és szol- 
gáltatások betöltésével induljon el, a Recovery Console pe- 
dig a számítógép állapotától függetlenül mindig használha- 
tó. Ebben az írásban ezeket ismertetjük, és néhány esetta- 
nulmány segítségével bemutatjuk használatukat. 


Bevezető 

Külső gyártó által készített szoftverek, vagy eszközmeghajtók 
telepítése elindíthatatlanná teheti a számítógépet. Erre példa 
lehet az, amikor a számítógép lefagy, egy , stop" hibaüzenetet 
kapunk, vagy nem vagyunk képesek bejelentkezni. Sok esetben 
a probléma megoldható egy szolgáltatás engedélyezésével 
vagy letiltásával, vagy az eszközmeghajtó lecserélésével. 

A Microsoft Windows NT korábbi verzióinál nem lehetett egy- 
szerűen, (helyi vagy távoli) bejelentkezés nélkül letiltani a 
szolgáltatásokat. A legtöbb esetben egy másik NT-t kellett az 
eredeti mellé telepíteni, hogy elérjük a meghibásodott rend- 
szer regisztrációs adatbázisát vagy fájlrendszerét. Ezért telepí- 
tette sok rendszergazda az operációs rendszert FAT partícióra. 
A Windows 2000-ben két olyan eszköz van, melynek segít- 
ségével hozzáférhetünk az el nem induló rendszerhez. Ezek 
a csökkentett mód, és a Recovery Console. A csökkentett 
mód az indítómenüből érhető el, és használatakor a Win- 
dows 2000 indításakor csak a minimálisan szükséges szol- 
gáltatások indulnak el, így lehetővé téve például egy hibás 
eszközmeghajtó, vagy egy szolgáltatás eltávolítását. 

A Recovery Console (amit ,, Command Console"-nak vagy "Re- 
pair Console"-nak is szoktak hívni) egy másik eszköz, ami az 
elindulni képtelen számítógép javítására, és a hibák felderíté- 
sére használható. A csökkentett móddal ellentétben a Reco- 
very Console-nak nincs grafikus felülete, hanem parancssorra 
alapuló eszköz. A Recovery Console többek között használha- 
tó a Chkdsk futtatására, egy hibás fájl lecserélésére, vagy akár 
egy szolgáltatás, vagy eszközmeghajtó letiltására is. 


Csökkentett módú rendszerindítás 

A csökkentett mód közvetlenül a karakteres üzemmódú boo- 

toláskor, még a fekete képernyőn, az F8 megnyomása után ér- 

hető el: az Advanced Options menübe jutunk, ahol a követke- 
ző lehetőségek közül választhatunk: 

"b Safe Mode (csökkentett mód). Ennek választásakor az 
operációs rendszer csak a számítógép indításához elen- 
gedhetetlen eszközmeghajtókat (például egér, billen- 
tyűzet) tölti be. 

"8 Safe Mode with Networking (csökkentett mód hálózattal). 
Az előzőhöz hasonló, de az alapvető hálózati szolgálta- 
tásokat is elindítja. 
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Safe Mode with Command Prompt (csökkentett mód pa- 
rancssorral). Hasonló a Safe Mode-hoz, de a Windows 
Explorer nem indul el (a Cmd.exe indul kezelőfelületként) . 
Enable Boot Logging (rendszerindítás közbeni naplózás 
engedélyezése). Ha ezt az opciót választjuk, létrejön a 
WindowsKönyvtárMtbtlog.txt naplófájl, melyből látha- 
tó, hogy mely szolgáltatások és eszközmeghajtók indí- 
tása volt sikeres vagy sikertelen. 

Enable VGA Mode (VGA mód engedélyezése) . VGA módban 
indítja a számítógépet, ezzel lehetővé teszi az alapér- 
telmezett megjelenítési beállítások megváltoztatását. 
Főleg akkor hasznos, ha a képernyő felbontását túl ma- 
gasra állítottuk. 

Last Known Good Configuration (rendszerindítás az utolsó 
ismert jól működő rendszerbeállítások alapján). 
Directory Services Restore Mode (címtárszolgáltatások 
visszaállítása). Ez a tartományvezérlőkön használható indí- 
tási mód, ami lehetővé teszi az Active Directory adatbázi- 
sának javítását, vagy visszaállítását szalagos mentésről. 
Debugging Mode (hibakeresési mód). Hibakeresési (debug) 
módban indítja a számítógépet. A hibakeresési infor- 
mációkat a COM2-re (ez az alapértelmezett), vagy a 
COM1-re küldi (ha nincs COM2 a számítógépen). 

Boot Normally (normál rendszerindítás). 

A Windows 2000 operációs rendszer indítója (loader) szabá- 
lyozza az ehhez a menühöz való hozzáférést. Ha az indítóme- 
nü már eltűnt, még mindig van lehetőség a menü elérésére az 
F8 megnyomásával, de csak a színes Windows 2000 indítóké- 
pernyő megjelenése előtt. Egy menüpont kiválasztásakor a 
kért opció megjelenik a képernyő alján, de csak akkor, ha az 
indítómenün még nem jutottunk túl, különben a rendszer in- 
dítása folytatódik (természetesen a kért mód használatával) . 


Ja 
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5 ...most nyomjunk F8-at... 





5 ...az Advanced Options menü eléréséhez! 


Ha ugyanazon a számítógépen használunk Windows 2000- 
et és Windows NT 4.0-t, az Advanced Options menü esetleg 
nem elérhető. Ennek az lehet az oka, hogy az NT 4.0-t a 
Windows 2000 telepítése után telepítettük. Ez esetben cse- 
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réljük le a Windows NT 4.0 indítófájljait (az Ntldr-t és az 
Ntdetect.com-ot) a Windows 2000-es verziókra. 


Az elindított szolgáltatások listája 

Csökkentett mód választása esetén csak a lehető legkeve- 
sebb szolgáltatás indul el. A választott opció alapján a kö- 
vetkező regisztrációs adatbázis bejegyzésben szereplő szol- 
gáltatások és eszközmeghajtók indulnak el: 


HKEY LOCAL MACHINENSYSTEMÍCurrentControlsSett 


4 Controllsafeboot 


Az e bejegyzés alatt található Minimal és Network kulcsok- 
ban találhatók meg a Safe Mode és a Safe Mode with Net- 
working opciókhoz tartozó szolgáltatások listái. 





Registry Editor - (HKÉY. LOCAL. MACHINE on Local Machine) 


2]jeNo Neme; - REG SZ : Service 
CO PriorityControl 
(OI ProdudOptions 
(A Redbook 
E SaleBoot 
Ca Minimal 
E Network 






5 Ki gondolta volna, hogy elvileg átállíthatjuk, mi in- 
duljon az egyes Safe módokban? De azért ne babráljuk... 


A Minimal kulcs alatt található azoknak a szolgáltatásoknak 

és eszközmeghajtóknak a listája, melyek a Safe Mode és a 

Safe Mode with Command Prompt opció választása esetén 

elindulnak. Ezek a következők: 

Eszközmeghajtók 

"B Az adott géphez csatlakoztatott tárolóeszközök meghaj- 
tói (CD-ROM és Jaz meghajtók, merevlemezek) 

"8 Beviteli eszközök (billentyűzet, egér) 

- Alap videokártya meghajtó (VGA) 

"8 Tárolóeszköz-vezérlők meghajtói (IDE/SCSI vezérlők) 

Szolgáltatások 

"8 Event log 

"8 Logical Disk Manager 

"8 Plug and Play 

"8 Remote procedure call (RPC) 

A Network kulcs alatt található azoknak a szolgáltatásoknak 

a listája, melyek a Safe Mode with Networking opció válasz- 

tása esetén indulnak el. Ha ezt az opciót választjuk, a kö- 

vetkező eszközmeghajtók és szolgáltatások indulnak el: 

Eszközmeghajtók 

"0 A Minimalnál felsorolt eszközökön kívül a hálózati kártyák 
meghajtói (ide értendők a például a PCMCIA eszközök is). 

Szolgáltatások 

"8 A Minimalnál felsorolt szolgáltatások 

"8 Computer browser 

6 Dynamic Host Configuration Protocol (DHCP) client service 

"5 Domain Name System (DNS) resolver cache 


"8 Messenger 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
2001. 10. 


8 Netlogon 

8 Server 

- TCP/IP NetBIOS helper 

8 Workstation 

Azoknak a szolgáltatásoknak a listáját, melyek mindegyik 
csökkentett módú indításkor elindulnak, nem szabad meg- 
változtatni. Lehet, hogy szeretnénk, ha egy adott szolgál- 
tatás mindentől függetlenül elinduljon, és elérhető legyen, 
de lehet, hogy éppen ez a szolgáltatás okozza a problémát. 


Környezeti változó 

Ha bármely csökkentett módú indítást választjuk, a 
SAFEBOOT OPTION környezeti változó jelzi azt a módot, 
amellyel a számítógép elindult. Ez a változó olyan progra- 
mok futtatásakor hasznos, melyek a számítógép állapotától 
függő műveleteket hajtanak végre. Ez lehet például olyan 
jelentéskészítő eszköz, ami a számítógépen fut, és a válto- 
zó értékétől függően a diagnosztikai információkat a szá- 
mítógép merevlemezére, vagy a hálózaton előre meghatáro- 
zott helyre menti. Az eszköz induláskor meghatározza a 
számítógép állapotát, és az információk mentéséhez szük- 
séges megfelelő műveletet. 

A SAFEBOOT OPTION környezeti változó a következő értéke- 
ket veheti fel: Minimal, Network, vagy DsRepair. Ha a szá- 
mítógépet a Safe Mode vagy Safe Mode with Command 
Prompt opcióval indítjuk, a SAFEBOOT OPTION változó ér- 
téke a Minimal lesz. A SAFEBOOT OPTION változó értéke 
csak a Windows 2000 Server vagy Windows 2000 Advanced 
Server tartományvezérlőkön lehet DsRepair. 


Példák a használatra 

1. példa 

Tegyük fel, hogy veszünk egy új programot, vagy eszközt, 
amely szolgáltatásként telepítődik (nevezzük AzÉnSzolgál- 
tatásom-nak). Miután befejeztük a telepítést, és újraindí- 
tottuk a számítógépet, a "Stop 0x0000021a" hibaüzenetet 
látjuk a kék képernyőn amelynek leggyakoribb okozója egy 
usermódban futó folyamat, de az alábbit például szántszán- 
dékkal okoztam, így: 


kill winlogon —-f 





5 Winlogon hiányában... 


Mivel az utolsó változtatás az AzÉnSzolgáltatásom telepítése 
volt, megpróbáljuk csökkentett módban indítani a számítógé- 
pet. Nem meglepő módon elindul és be tudunk jelentkezni. 
Gyanús, hogy az AzÉnSzolgáltatásom okozta a hibát, ezért tilt- 
suk le az indítását a Computer Management használatával, és 
indítsuk újra a gépet (most ne válasszuk a Safe Mode opciót). 
A számítógép elindul, és be tudunk jelentkezni. Távolítsuk el 
a programot az Add/Remove Programs eszköz segítségével. 


2. példa 

A csökkentett mód akkor is használható, ha bizonyos összete- 
vők károsodtak, vagy véletlenül le lettek törölve. Például ha az 
Explorer.exe fájl károsodott, az asztal (desktop) nem jelenik 
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meg. Ez esetben indítsuk el a számítógépet, és válasszuk a Sa- 
fe Mode with Command Prompt opciót az Advanced Options 
menüből. Ekkor a Cmd.exe-t használjuk kezelőfelületként az 
Explorer.exe helyett, és lecserélhetjük a hibás Explorer.exe-t 
egy új, hibátlan példányra. 

Minden csökkentett mód opció kiválasztása esetén (a Safe 
Mode with Command Prompt-nál is) be kell jelentkezni, hogy 
hozzáférhessünk a számítógéphez. A Safe Mode with Net- 
working kivételével a bejelentkezés az adott gépen levő SAM 
(Security Accounts Manager) adatbázis alapján történik. 


3. példa 

Van egy számítógépünk (laptop), amelyet több irodában is 
használunk. Minden munkahelyen külön monitor van. A je- 
lenlegi munkahelyünkön levő monitor működik magas kép- 
frissítéssel és felbontással, de amikor átmegyünk egy másik 
irodába, az ottani monitor nem működik az előzőnél alkalma- 
zott beállításokkal. Mivel nem látunk semmit a monitoron, 
nem tudunk bejelentkezni, és megváltoztatni a beállításokat. 
Ebben az esetben újra kell indítani a számítógépet, és az 
Enable VGA Mode-ot választani az Advanced Options me- 
nüből. Így a számítógép normálisan indul, de VGA felbon- 
tást használ, így meg tudjuk változtatni a beállításokat. 


A Recovery Console 

A Recovery Console arra használható, hogy hozzáférjünk a 
számítógéphez, amikor az egyáltalán nem hajlandó elindulni 
(még a csökkentett módú opciók használatával sem) . Az Admi- 
nistrator felhasználói fiók és jelszó használatával hozzáférhe- 
tünk a Windows 2000 rendszerfájlokhoz, futtathatunk néhány 
beépített diagnosztikai eszközt (például Chkdsk), és korláto- 
zottan bár, de hozzáférhetünk a regisztrációs adatbázishoz, 
hogy letilthassunk, vagy engedélyezhessünk szolgáltatásokat. 
Ezt FAT16, FAT32 vagy NTFS partíciókon tehetjük meg. 

A Recovery Console futtatásához szükség van a Windows 
2000 Professional, a Windows 2000 Server vagy a Windows 
2000 Advanced Server CD-ROM-ra, és egy rendszerindítás- 
ra képes CD-ROM meghajtóra. Azokon a számítógépeken, 
melyekben nincs az El Torito specifikációnak megfelelő CD- 
ROM meghajtó, a négy indítólemezt kell használni, vagy 
létre kell hozni azokat a CD-ROM-ról. 

Indítólemezek létrehozásához készítsünk elő négy üres 
floppy lemezt, és futtassuk a Windows 2000 CD-ROM Boot- 
disk mappájában található Makeboot.bat fájlt. 

Most indítsuk el a számítógépet. A CD-ROM, vagy az 1. in- 
dítólemez legyen a meghajtóban, és kövessük a képernyőn 
megjelenő utasításokat. Amikor a Welcome to Setup üze- 
net megjelenik... 





...nyomjuk meg az R-t, hogy kiválasszuk a Repair a Win- 
dows 2000 Installation (telepített Windows 2000 javítása) 
opciót. Amikor a Windows 2000 Repair Options (javítási 
opciók) párbeszédablak megjelenik... 
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merneuie teker eesjze tease B EENNNNNNNNNTONOAONZÉT 
. .. nyomjuk meg a C-t. Ezzel elindítottuk a Recovery Conso- 
le-t. Ha R-t ütöttünk volna, az Emergency Repair folyamat- 
ba kerültünk volna (lásd később). A következő képernyőn a 
telepített operációs rendszerek listája látható. A szám 


leütésével kiválasztható a kívánt Windows 2000 rendszer. 





Ezután gépeljük be a helyi Administrator jelszavát (a nevét nem 
kell, a well-known-SID alapján választódik ki!), és nyomjuk meg 
az Enter-t. A Recovery Console-nál a helyi Administrator jelszó 
megadása szükséges a rendszert tartalmazó kötet eléréséhez. 
Három lehetőség van a helyes jelszó megadására, ha nem sike- 
rül, a számítógép újraindul. Ha a gépen nem találhatók Windows 
2000 rendszerfájlok, a parancssor automatikusan megjelenik. 

A jelszó elfogadása esetén megjelenik a parancssor, és a 
választott rendszer SystemRoot mappájában kezdhetjük 
ténykedésünket (például C: IWinnt). 

A Recovery Console-lal általános hibaelhárítási tevékeny- 
ségeket végezhetünk (például a Chkdsk eszköz futtatása 
egy köteten, fájlok másolása CD-ROM-ról a merevlemezre) , 
melyek segítségével a számítógép ismét indítható állapot- 
ba kerülhet. Csak befelé másolhatunk, kifelé (a számító- 
gépről lemezre vagy bármi másra), csak akkor, ha a bizton- 
sági házirend ezt megengedi (lásd később). 

Nem kell mindig a CD-ROM-ot, vagy az indítólemezeket hasz- 
nálni a Recovery Console indításához, ugyanis a Windows 
2000 CD-ről telepíthető is. Gépeljük be az alábbi parancsot. 


x:)i386Wwinnt32 /cmdcons 


(ahol x a CD-ROM meghajtó, vagy a Windows 2000 telepítő- 
készletet tartalmazó megosztás betűjele). 

Ez a parancs a Recovery Console futtatásához szükséges 
fájlokat a rendszert tartalmazó kötet gyökerében létrejövő 
Cmdcons rejtett mappába telepíti, és hozzáad egy bejegy- 
zést a Boot.ini fájlhoz. Ezután az indítómenüben meg fog 
jelenni a Windows 2000 Recovery Console opció is az ope- 
rációs rendszerek között. Kb. 7 MB helyet igényel. 


A parancsok listája 
Az alábbi parancsok használhatók a Recovery Console-ban: 


Attrib Delete fixmbr more 

Batch Dir format rd 

Cd Disable Help ren" 

Chdir diskpart listsvc rename 
Chkdsk Enable Logon rmdir 

Cls Exit Map systemroot 
Copy Expand Md type 

Del Fixboot Mkdir set 
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A Recovery Console automatizált telepítése 

Ahogy az előzőekben leírtuk, a Recovery Console futtatható a 
számítógép merevlemezéről is. Ha Windows 2000-et futtató 
gépeket helyezünk üzembe, és automatizáltan akarjuk telepí- 
teni a Recovery Console-t, használjuk a következő parancsot: 


winnt32.exe /cmdcons /unattend 


Futtatható a Windows 2000 automatizált telepítése során is, 
(a válaszfájl [RunOnce] részébe kell beírni) , és használható a 
GUI módú telepítés során a Cmdlines.txt fájl használatával 
is. A válaszfájlról és a Cmdlines.txt fájlról további informá- 
ció a Microsoft Windows 2000 Resource Kit-ben található. 
Ha a Sysprep eszközt használjuk, hogy a számítógépeket le- 
mezduplikálást használva helyezzük üzembe, csak akkor ja- 
vasolt a Recovery Console telepítése a helyi merevlemezre, 
ha az összes telepítendő számítógépben ugyanolyan típusú 
és méretű merevlemez van, mint a forrásgépben, és 
ugyanazt a fájlrendszert is használják. 


Házirend használata a Recovery Console biztonságossá- 
gának szabályozásához 
A Recovery Console-ban sok olyan opció van, ami segíthet 
az el nem induló számítógép helyreállításában. Ezek közül 
van néhány olyan, melyek engedélyezhetők, vagy letiltha- 
tók, hogy a számítógép biztonságosabb, vagy könnyebben 
kezelhető legyen, amíg ebben a módban fut. Például a set 
parancs a következő paraméterek beállítására használható: 
"2 AllowWildCards. bizonyos parancsoknál engedélyezi a he- 
lyettesítő karakterek használatát (például del "." parancs). 
"0 AllowAllPaths. lehetővé teszi az összes útvonal elérését 
az összes köteten. 
"2 AllowRemovableMedia. Lehetővé teszi, hogy a számítógép- 
ről floppy, vagy Jaz, vagy Zip lemezekre másoljunk fájlokat. 
"b NoCopyPrompt. Nem jelenik meg figyelmeztetés, ha egy 
fájlt felül akarunk írni. 
Ezek a paraméterek alapértelmezésben , False"-ra (nem en- 
gedélyezett) vannak állítva és változtathatóságukat házirend 
szabályozza. Az alapértelmezett viselkedés az, hogy a rend- 
szergazda automatikus bejelentkezése és a set parancs hasz- 
nálata nem engedélyezett. Az alapértelmezett házirend 
megváltoztatásához szükséges lépéseket alább részletezzük. 


Tartományhoz nem tartozó számítógépek 

A tartományhoz nem tartozó gépeken a helyi biztonsági há- 

zirendet kell módosítani. A házirendet minden egyes gépen 

módosítani kell, ahol el akarunk térni az alapértelmezett 

beállításoktól. A helyi biztonsági házirend módosításához a 

következőket kell tennünk: 

1. Start menü -- Settings -: Control Panel -: Administrative 

Tools -s Local Security Policy 

2. Amikor a Local Security Settings elindul, válasszuk az 

alábbi mappákat: 

"8 Local Policies 

"8 Security Options 

3. A beépülő modul jobb ablakában keressük meg a követ- 

kező két házirendet: 

"b Recovery Console: Allow automatic administrative logon 

6 Recovery Console: Allow floppy copy and access to all 
drives and all folders 
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4. Alapértelmezésben ezek a házirendek le vannak tiltva. 
Engedélyezésükhöz kattintsunk a jobb gombbal a házirend 
leírására, majd kattintsunk a Securityra. 

5. Amikor a Local Security Policy Setting párbeszédablak 
megjelenik, kattintsunk az Enabled-re, majd az OK-ra. 
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5 A Recovery Console biztonsági beállításait még jóval a 
katasztrófa bekövetkezte előtt gondoljuk át! 


Tartományhoz tartozó számítógépek 

A fent bemutatott lépések ugyanúgy alkalmazhatók a tarto- 
mányi számítógépeken is, de ha a tartomány Windows 2000 
alapú, a tartományi házirend felülbírálja az összes helyi házi- 
rendet. Ez esetben javasolt tartomány-szintű házirend hasz- 
nálata (ennél is alkalmazhatók a fent bemutatott lépések). 


A Recovery Console használata tartományvezérlőkön 

A Recovery Console Windows 2000-et futtató tartományve- 
zérlőkön is használható. Minden, amit ebben a részben leír- 
tunk, érvényes a tartományvezérlőkre is, egy apróság kivé- 
telével. Az Administrator jelszó, ami a Recovery Console 
elindításához használható, az lesz, ami a számítógép tarto- 
mányvezérlővé válásakor volt (SAM jelszó). Ezután ez a jel- 
szó már nem fog megváltozni még akkor sem, ha közben 
megváltoztatjuk az Administrator jelszót. 


Példák a használatra 

1. példa 

Egy frissített eszközmeghajtót telepítünk (Driver1.sys) a tá- 
rolóeszköz-vezérlőhöz, amit egy neves gyártótól (OEM) vet- 
tünk. Ez a frissítés lecseréli a Microsoft által szállított esz- 
közmeghajtót, ami a számítógép telepítésével egyidejűleg 
települt. Amikor újraindítjuk a számítógépet, egy ,Stop 
0x7b" hibaüzenetet kapunk (inaccessible boot device - a 
rendszer indításához szükséges eszköz nem elérhető) . Amikor 
megpróbáljuk a rendszert csökkentett módban indítani, 
ugyanezt a hibaüzenetet kapjuk. 

A hiba elemzése során látjuk, hogy az OEM által készített esz- 
közmeghajtó nem működik jól az adott vezérlőkártyával. Hasz- 
náljuk a Windows 2000 CD-ROM-ot a Recovery Console elindítá- 
sához. Miután bejelentkeztünk, keressük meg az OEM által ké- 
szített eszközmeghajtót, és cseréljük le az eredeti Microsoftos 
verzióra. Ezután már el tudjuk indítani a számítógépet. 


A Recovery Console használatakor a Windows 2000 CD- 


ROM-ról másolt fájlokat nem kell , kicsomagolni" (ex- 
pand), mert ez automatikusan megtörténik. 
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2. példa 

Egy Windows 2000 Serveren szoftveres RAID 1 (tükrözés) 
megoldást alkalmazunk a rendszerpartíció tükrözésére. A 
Disk 0 merevlemez meghibásodik, a rendszer pedig tovább 
működik a Disk 1-ről. A rendszergazda kicseréli a meghibá- 
sodott merevlemezt egy újra. A számítógép az újraindítás- 
kor nem tud Windows 2000-ret indítani, mert az operációs 
rendszernek a tükrözött lemezről (disk 1) kellene elindul- 
nia, de a boot.ini-ben az ARC (Advanced RISC Computing) 
elérési út az új merevlemezre (disk 0) mutat. 

Mivel nem tudjuk, hogy milyen ARC elérési út szükséges, 
indítsuk el a Windows 2000 CD-ROM-ról a Recovery Conso- 
le-t. Ezután a következő parancs segítségével megtudhat- 
juk a helyes ARC elérési utat: 


map arc 


Ez a parancs megmutatja az összes merevlemez és összes 


3. példa 

A számítógépünk nem indul, ezért hívunk egy nálunk oko- 
sabb embert. A szakember magával hoz egy Windows 2000 
CD-ROM-ot, melynek segítségével elindítja a Recovery Con- 
sole-t, és egy lemezt, amelyen egy Recover.txt nevű fájl 
található. Miután elindítja a Recovery Console-t, a hibael- 
hárítás lépései automatizálhatók kötegelt (batch) paran- 
csok segítségével. Emberünk ismeri a batch parancsot, 
mely így működik: 


batch a:lrecover.txt 


Tulajdonképpen tetszőleges nevű és kiterjesztésű TXT fájl- 
ban összegyűjthetjük a végrehajtandó parancsokat, a 
batch parancs nem kényes a nevekre. A mi emberünk text- 
fájlja az alábbi sorokat tartalmazza: 


Set allowRemovableMedia - True 

Set NocopyPrompt - True 

Fixboot c: 

FixMbr 

Chkdsk c: 

Attrib -r c:intldr 

Attrib -r c:Intdetect.com 

Copy da:Niz86intldr c:(ntldr 

Copy d:Viz8g6intdetect.com c:Intdetect.com 
Attrib tr c:(ntldr 


Attrib tr c:Intdetect.com 
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WINDows 2000 RECOVERY CONSOLE 
Kijavítja a boot sectort és az MBR-t (Master Boot Record), 
lefuttatja a chkdsk parancsot a rendszerpartíción, új rend- 
szerindító fájlokat (Ntldr és Ntdetect.com) másol a számí- 
tógépre, és a megfelelő attribútumokat is beállítja. Igazán 
leleményes fickó! 


4. példa 

A gép nem indul, mert egy utólagos NT 3.51 telepítés 
(sic!) felülírta NTDETECT.COM-ot és az NTLDR-t. Be is má- 
solhatnánk a helyes verziókat, de mi a Recovery Console 
beépített parancsaira bízzuk magunkat. 


C:Nfixboot 


Ez remekül újraírja a bootszektort, de - mint újraindulás- 
kor kiderül - nem cseréli vissza a fenti két fájlt. Ekkor az 
Emergency Repair megoldás mellett döntünk. Rendszertöl- 
tés CD-ről, press R, press R again, majd press M (manual 
repair), s a következő lehetőségek tárulnak elénk: 





Totózzunk! Vajon melyik javítja ki a fenti két fájlt? 

8 Az lInspect Startup Environment nevével ellentétben nem 
foglalkozik az indításhoz nélkülözhetetlen fájlokkal 
(akkor mit csinál??) 

-8 Az lInspect Boot Sector azonos hatású a Recovery Console 
fixboot parancsával - azaz szintén nem törődik a fájlokkal 

"8 A Verify System Files pedig ugyebár a WINNT könyvtárra 
vonatkozik 

Tehát egyik sem? Nos, ha hiszünk a feliratoknak, és egye- 

sével, logikus sorrendben kipróbáljuk a fenti opciókat, ki- 

derül, hogy mégiscsak a Verify System Files segít rajtunk. 

Végül press L, mivel nincs a birtokunkban ERD (Emergency 

Repair Disk flopilemez), majd press Enter, és beindul a re- 

szelés. Amikor látjuk, hogy a Verify System Files nekiáll a 

WINNT könyvtár reparálásának, press F3 (-0uit). 


Fóti Marcell 
marcellfonetacademia.net 
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Most egy igazán haszontalan algoritmusokról írok önöknek: 
olyasmiről, ami kizárólag az adatok összekavarására és szét- 
trancsírozására alkalmas: a hash, vagy magyarul tördelőal- 
goritmusokról. Egy biztonsággal foglalkozó könyvben olvas- 
tam azt a hasonlatot, hogy a hash algoritmus olyan, mint 
a húsdaráló, a beléhelyezett adat széttrancsírozódik. A fo- 
lyamat egyirányú: nyúlból 
könnyedén készíthető fa- 
sírt, de fasírtból nyúl...? 
(A hash szó jelentése szó 
szerinti — fordításban: 
darálék, darálthús.) 









5 Egy hash algoritmus blokkdiagramja :-) 


Mindennapjaink adatainak hasznosságához nem fér kétség; 

dokumentumaink, adatbázisaink, táblázataink, jelszavaink 

nélkül lehúzhatnánk a rolót. De vajon mi a csudára jó egy 
word dokumentum, vagy egy jelszó fasírtja? 

Ha ez a fasírt közönséges, felismerhetetlen hústrutymó len- 

ne, bizony nem lehetne értelmesen felhasználni, azonban a 

hashalgoritmusok kimenete olyan darálékot ad, mely 

"0 (jobbára) egyértelműen utal az eredeti adatokra, de 
legalább az a feltétel teljesül, hogy egy adott dokumen- 
tumból mindig ugyanaz a hash állítható elő. 

"8 minden megismételt futásra azonos. Az algoritmus visel- 
kedése determinisztikus. A megismételt futásnak külö- 
nös jelentősége van elosztott környezetekben, ahol 
ugyanaz a hash algoritmus a hálózat különböző gépein, 
egymástól függetlenül futkos. 

"0 nem teszi lehetővé az eredeti adatok előállítását. Fasírt- 
ból ne lehessen nyulat alkotni! 

Időről időre felröppennek hírek bizonyos algoritmusok fel- 

töréséről, s ilyenkor mindig titkosítások megtörésére gon- 

dolunk, pedig egy hash algoritmus feltörése legalább olyan 

izgalmas feladat. Ha a fasírtból visszaállítható a nyúl, a 

hash feltörtnek tekinthető. 


Mire jó? 

Ahogy a fasírt univerzális étel, úgy a hash eredménye is 
igen sokoldalúan hasznosítható. Az alábbi néhány példa rá- 
világít a méltatlanul lenézett darált hús informatikai fel- 
használásának sokoldalúságára: 

1. Jelentős szerepet kap hálózati bejelentkezéseinknél, 
hogy jelszavainkat ne kelljen olvasható formában átvinni a 
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hálózaton. Ilyenkor titkosítás helyett használjuk, mert 
megfelelően ravasz módon felhasználva ugyanolyan bizton- 
ságos jelszóátvitelt tesz lehetővé, mint egy titkosítóalgo- 
ritmus, és még csak kulcscsereberére, vagy biztonsági tanú- 
sítványra (Certificate) sincs szükség. 

2. Napjaink oly divatos technológiája, a digitális aláírás 
sem létezne megfelelő hashalgoritmus nélkül. Itt az algo- 
ritmus visszacsinálhatatlanságát aknázzuk ki. 

3. Minél olcsóbb a RAM, annál több van belőle, s minél töb- 
bet használunk, annál több adatunk kerül gyorstárolókba 
(cache). A hashalgoritmusok döbbenetes módon szerepet 
kapnak a cachememóriák kezelésében - nélkülük huszad- 
akkora teljesítményre lennénk képesek. 

4. Még az adatbáziskezelők is profitálnak a fasírtból. Az SOL 
Server hash-joint használ hatalmas és rendezetlen táblák 
közötti kapcsolatok (join) megvalósításánál. 

Remélem sikerült ha érdeklődést nem is, de legalább gya- 
nakvást kelteni a hashalgoritmusok iránt, így áttérhetünk a 
konkrétumokra. 


1. felhasználás: autentikáció 

Napjaink ezergépes vállalati hálózatainál nélkülözhetetlen, 
hogy minden erőforrás felhasználását személyre szabottan 
tudjuk beállítani, engedélyezni és tiltani. Ehhez nincs is 
másra szükség, mint a hálózat számítógépei előtt üldögélő 
felhasználók egyszerű és egyértelmű azonosítására. Sokféle 
módszer szóbajöhet, de manapság egyértelműen a név-itjel- 
szó típusú bejelentkezési forma a legelterjedtebb, mivel né- 
mi kényelmetlenség árán megfelelően stabil felismerési le- 
hetőséget biztosít - amíg a jelszavak nem kerülnek közkéz- 
re. Ez ellen nyilvánvalóan úgy védekezhetünk, hogy nagy. 
ívben elkerüljük a titkosítatlan jelszóátvitel összes formá- 
ját, s lemondunk többek között az FTP-ről... 

Titkosítsunk! 

Mivel? Hát pl. 3DES-sel, mert az jó erős! Ha a titkosított átvi- 
tel mellett döntünk, felmerül egy valóban bosszantó probléma: 
mivel napjaink összes populáris titkosítóalgoritmusának (DES, 
3DES) minden részlete, sőt forráskódja is ismert, kénytelenek 
volnánk a titkosítókulcsok rejtegetésével biztosítani az illeték- 
telenek távoltartását, hisz ha nem így tennénk, saját 3DES- 
ükkel olyan szépen visszafejtenék a jelszót, hogy ihaj! 

A bejelentkezés megkezdése előtt tehát , titokban" el kellene 
juttatni a munkaállomásokra a megfelelő (random), egyszer- 
használatos 3DES titkosítási kulcsot. Igen ám, de hogyan? 
Hálózaton? Ahhoz előbb el kellene juttatni egy másik titkos 
kulcsot, aminek titkos eljuttatásához egy harmadik kulcs kel- 
lene, amit titkosítva viszont csak egy negyedik kulccsal jut- 
tathatnánk át, amihez kellene egy ötödik... Milyen jó is len- 
ne, ha a kezdő 3DES kulcsot valahogy úgy oda lehetne vará- 
zsolni a munkaállomásokra, hogy Hacker Henry és Claudia 
Scniffer ne kaphassa el! Mondjuk postagalambbal? Ejnye, a 
szimmetrikus titkosítóalgoritmusok úgy tűnik felsültek! 
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És ekkor egy hirtelen ötlettel eszünkbe jutnak a szintén 
publikált, közismert (MD4, MD5, SHA) hashalgoritmusok. 
Hogyan lehetne ezekkel dolgozni? Az ötlet alapja az a 
tény, hogy a hashalgoritmusok egyirányúak. Egy jel- 
szóhash-t (fasírt) minden további nélkül kirakhatunk a há- 
lókábelre, mert ha ezt valaki elkapja, maximum mégegy- 
szer ledarálhatja, hogy finomabb legyen - de nyuszimuszi 
az életben nem lesz belőle. 
Tartomány 
vezérlő 


Munkaállomás 
Babuka: tt 


Samuka: tetst 
... 








aa 
Név: Samuka 
Jelszó: tetemre 
kittek kikkt 


o [e] a sg 


e 


9 Jelszóellenőrzés bejelentkezéskor 


A jelszókiértékelés menete a következő: 0 a munkaállo- 
más bekéri a felhasználó jelszavát, és O ráereszti a maga 
hashalgoritmusát. A végeredményt a felhasználónévvel 
együtt elküldi a tartományvezérlőnek 8), aki szintén nem 
tud fasírtból nyulat eszkábálni, de neki is van egy nyula! 
Megvan nála ugyanis a júzer éppen érvényes jelszava 9. 
Ledarálja Ő, s a nyúl borzalmas földi maradványait össze- 
hasonlítja 6 a hálózaton át megkapott fasírttal. Ha a ket- 
tő egyezik, a két nyúl is egyforma volt. Fantasztikusan 
egyszerű ugye? És ráadásul feltörhetetlen...?! 


És a LOpthCrack? 

Hát igen. Az [1] címről letölthető LOpthCrack (ejtsd: 
luftkrekk) már évek óta tudja mindazt, ami lehetetlen: 
hashalgoritmussal titkosított jelszavakat , visszafejteni". 
Valóban megmondja a hálózaton látott hessek alapján az 
eredeti jelszót, de NEM visszafejtéssel, hanem sok-sok nyúl 
egymás utáni ledarálásával, másképpen próbálkozással. 
(Mégpedig kétféle módon: szótárral, majd ha az kimerült, 
szisztematikusan végigpróbálgatva a lehetséges kombináció- 
kat. Ez utóbbit brute force módszernek hívják. A [2] címről 
letölthető törőszótár a magyar nyelvhez készült, a weben 
leggyakrabban előforduló szavak szerepelnek benne.) S ami 
tíz évvel ezelőtt merő fikció volt, az öt éve már bizonyítot- 
tan - bár lassan - működött, ma pedig száguld. Az egyre 
nagyobb teljesítményű gépek nyilvánvalóan egyre több 
nyulat darálnak le egységnyi idő alatt, így a jelszófeltörés 
is egyre könnyebb feladat. A régi típusú 052/Windowsos 
(LanMan) jelszavak könnyű feltörhetőségéhez azonban 
még egy fontos dolog hozzájárult. 
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WINDOws 2000 HASH! 
Security by obscurity 

Avagy a ködösítéses titkosítás. 

Ha valaki titkosítási algoritmus bevezetésén gondolkodik, iz- 
zó vassal kergesse el azokat a sarlatánokat, akik saját fejlesz- 
tésű, hipererős megoldásokkal jelentkeznek, de nem árulják 
el az erősség mibenlétét. Ezek az alakok az esetek 10890- 
ában egyszerűen túl ostobák ahhoz, hogy megértsék a meg- 
lévő algoritmusokat, ezért hekkelnek valami ócskaságot, s 
azt hiszik, hogy mivel senki nem ismeri az algoritmust (XOR, 
eltolva az ábécében, sőt, szorozva a gondolt szám háromszo- 
rosával és hasonló gyíkságok) , tákolmányuk mindjárt megfejt- 
hetetlen is. Sokszor meglévő algoritmusokon ,tikosítanak" 
még egyet, ami a butaság legmagasabb foka. Ezek azok az al- 
goritmusok, melyek pofonegyszerű kriptoanalízissel (gyakori- 
ságfigyelés stb.) úgy nyílnak, mint a sufniajtó a szélben. Azt 
hihetnénk, hogy ebbe a csapdába nagy-nagy cégek nem sé- 
tálnak bele. Nos, ez nem így van. Az IBM-Microsoft duó által 
kifejlesztett LanMan hashalgoritmus egyik erősségét az adta, 
hogy nem publikálták az algoritmust. Ez az erő hónapokig 
tartott, utána egyszerűen visszafejtette a kódot egy lelkes 
egyetemista, s kitette az Internetre. Ennek nyolc éve. Ma 
már a Windows a szabványos Kerberos autentikációs proto- 
kollt használja, de Lan Managerek, 05/2-k és Windowsok ge- 
nerációinak kipusztulását kell kivárni, hogy mindenünnen el- 
tűnjön a LanMan (és az NTLM). 


Kitérő: a jelszóalapú bejelentkezés halála? 

A fenti gondolatmenetből következően (egyre gyorsabb gé- 
pek, egyre rövidebb brute force) egyre közelebb érünk ah- 
hoz a jövőbeni pillanathoz, amikor a jelszóalapú hitelesí- 
tésnek végleg befellegzik. Küzdhetünk a gépek ellen, de 
sajnos az egyetlen megoldás, ha a jelszavak egyre bonyo- 
lultabbá válnak. Egy jelszó legyen 

"8 hosszú 

2 bonyolult és 

8 könnyen megjegyezhető 

Ez a három szempont körülbelül annyira elégíthető ki egy- 
szerre, mint amit egy kőművessel szemben támasztunk 
(munkája legyen gyors, olcsó és jó minőségű). 

Hiszen ha egy jelszó hosszú és bonyolult, akkor nem kön- 
nyű megjegyezni: kiírjuk a monitorra. Ha hosszú és megje- 
gyezhető, akkor az emberi gyarlóság miatt nem bonyolult 
stb. Kiutat a SmartCard logon jelent, ahol a , jelszó" a nyil- 
vános kulcsunk, ami minimum 512 bit. Az emberi jelsza- 
vakhoz képest végtelenül hosszú, határtalanul bonyolult, 
és meg sem kell jegyezni! 


2. felhasználás: digitális aláírás 

Amit tudni akartál a digitális aláírásról, de nem merted 
megkérdezni: mi teszi lehetővé, hogy egy dokumentumról 
teljes bizonyossággal kijelenthetjük, hogy X.Y. írta, és azt 
senki meg nem módosította? Hát bizony a hash. Egészen 
pontosan az aláíró privát kulcsával titkosított hash. (Lám, 
hamarosan meg kell írnom az RSA algoritmust is.) 

Mit tud biztosítani a digitális aláírás? Pontosan azt, amit 
a hagyományos szignó: a dokumentumot bárki elolvashat- 
ja, de a rendelkezésére álló erőforrásokkal és időkerettel 
gazdálkodva" képtelen lesz meghamisítani. Ennek műkö- 
dése nagy vonalakban a következő (deszkamodel[) : 

1. végy egy elektronikus dokumentumot 
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WINDows 2000 HASH! 

2. titkosítsd saját privát kulcsoddal 

3. küldd el mindenkinek, de tedd mellé a publikus kulcsodat 
Minden címzett képes lesz ezek után a mellékelt publikus kulcs 
segítségével dekódolni és elolvasni az üzenetet, de egyikük 
sem lesz képes elolvasás után módosítani ÉS újra visszakódol- 
ni, mivel a privát kulcs mindvégig nálad van, volt és lesz. 
Deszkamodellünk óriási hátránya, hogy nem hűen tükrözi a 
valóságot. Ennek oka a nyílt kulcsú titkosításban keresen- 
dő: végtelenül lassan lenne képes akárcsak egy néhány tíz 
kilobájtos dokumentumot titkosítani (mert a titkosítás 
egyik lépése a dokumentum, mint irdatlan hosszú bináris 
szám felemelése a ,,kulcsadik" hatványra). Kellene ide egy 
olyan adatka, mely kicsi és aranyos (villámgyorsan végez ve- 
le az RSA), ám egyértelműen összefüggésbe hozható az 
eredeti dokumentummal. Na mi ez a számocska? A doku- 
mentumból képezett hash! Így a digitális aláírásképzés va- 
lósághű modellje a következő: 


A 


0 


2 trotázf 
E trotÁzf 


5 Digitális aláírás képzése 


1. végy egy elektronikus dokumentumot 
2. képezz belőle egy csinos kis hash-t 
3. a hash-t titkosítsd saját privát kulcsoddal 
4. a következőket csomagold egybe, és küldd el mindenkinek 
a. a dokumentumot 
b. a hash-t 
c. a publikus kulcsodat 
Az aláírás valódiságának ellenőrzése pedig így történik: 
1. vedd ki a csomagból a dokumentumot 
2. képezz belőle hash-t 
3. vedd ki a csomagból a publikus kulcsot és a titokhash-t 
4. nyisd ki a titokhash-t a publikus kulccsal 
5. hasonlítsd össze az általad a második lépésben készített 
hashértéket azzal, amit épp az imént dekódoltál 
6. ha a két érték egyezik, a dokumentum érintetlen 


3. felhasználás: cache 

A cache magyarul gyorstítótár. Vagyis célja valamilyen mű- 
velet gyorsítása. Triviálisan hangzik, de a cél eléréséhez so- 
kat kell gondolkodni! Minél nagyobb ugyanis a gyorsítótár, 
annál lehetetlenebb benne villámgyorsan megtalálni, hogy 
egy igényelt objektum benne van-e, vagy mégiscsak utána 
kell szaladni az eredeti tárolóhelyére. Szándékosan nem ne- 
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vezem nevén az eredeti tárolóhelyet, mert a RAM, mint las- 
sú tároló gyorstárazása is bőven találunk példát a pro- 
cesszorok ilyen-olyan gyorstárai esetében. 

Az lenne az ideális, ha nulla órjelciklus alatt megállapítható 
lenne, hogy amit keresünk, az ,kesselve" van-e már, ehhez vi- 
szont arra lenne szükségünk, hogy a cache minél intelligenseb- 
ben meg tudja mondani, mi van benne. Evilági példával élve: 
keressük, hogy melyik nebuló rakott rágógumit a tanítónéni 
székére. Néhány csibész esetén majdnem mindegy, hogy ön- 
ként jelentkezik-e a bűnös, vagy egyesével ki kell faggatnunk 
őket, de ha történetesen negyvenezer rosszcsontunk van, én az 
önkéntes megoldásra szavaznék: Pistike igenis álljon fel! 

Az önkéntes megoldást asszociatív memóriával érhetjük el, 
melynek működése a becsületes csibészek gyülekezetéhez ha- 
sonló: egyszer kell feltenni a kérdést, s a következő pillanat- 
ban Pistike már fel is áll. Egyszerűen nem kell végigkeresni a 
halmazt! Micsoda fantasztikus memória! Vajon miért nem 
ilyet használunk mindenhol? Mit vacakolunk mindenféle kere- 
sési algoritmusokkal? Mert - finoman szólva - nem olcsó mu- 
latság. Ahol azonban a keresgélés rombadöntené a gyorsító- 
tár teljesítménynövelő hatását, ott igenis találkozunk vele, a 
Pentium processzorok Translation Look-aside Buffer-e például 
asszociatív memóriát használ. Erről a múltkori mesterkurzu- 
son a memóriakezeléssel kapcsolatban tettem említést. 
Amikor azonban egyszerű merevlemezadatokat , kesselünk" , 
akkor olcsó, ezerforintos RAM-ban gondolkodunk, amely saj- 
nos egyet jelent azzal, hogy Pistikének esze ágában sincs 
bevallani tettét, és önként jelentkezni. Keresgélnünk kell. 
Egyszerűsítené a sok kis taknyos kivallatását, ha le tudnánk 
szűkíteni valahogy a kört azokra az ördögfiókákra, akik biz- 
tosan képesek lennének elkövetni a rágógumis csínyt. 
(Ettől a ponttól kezdve a hasonlatom kissé kirekesztővé vá- 
lik, bármely vélt hasonlóság ismert személyekkel kizárólag a 
véletlen műve! Ne feledjük: nem is rakott senki rágót a 
tanítónéni székére!) Alkossunk halmazokat: a világért sem 
tennének ilyet a szemüvegesek, és a lányok, azonban a kó- 
cos hajú és a szeplős fiúk gyanúsak nekem! Vallasuk ki elő- 
ször a szeplőseket, s ha egyikük sem vállalja, akkor a kóco- 
sokat. Én úgy gondolom, hogy már a szeplősök megríikatá- 
sa is eredménnyel járna, a többiek akár haza is mehetnek. 
IT terminológiával a történet így szól: van egy objektum- 
igény (blokk olvasása egy fájlból), rendelkezésre áll az ob- 
jektumkérést egyedivé tevő adathalmaz (fájlnév, beolvasási 
pozíció) , s ezek alapján meg kell állapítanunk, hogy a gyor- 
sítótárban ugyanebből a fájból ugyanez a darabka megta- 
lálható-e. A gyorsítótár minden eleme természetes módon 
magán viseli saját egyedi azonosítóját (fájlnévá-pozíció) , és 
ez alapján gyorsan meg is lehetne találni - ha nem lenne 
negyvenezer ilyen elem a tárban. Képezzünk belőlük cso- 
portokat! Itt egy olyan hash algoritmus segít, amelyik nem 
egyedi értékeket ad, hanem a bemenő adatok egy bizonyos 
csoportjára mindig ugyanazt (szemüvegesek), más csopor- 
tokra mást (lányok). (Egy ilyen algoritmus például a modu- 
lo 5, mely minden öttel osztható számot a nullás vödörbe 
rak, az egy maradék árán oszthatóakat az egyes vödörbe 
stb.) Valójában ez a fajta csoportosítás nem a keresés pil- 
lanatában történik meg, hanem az elem már eleve a maga 
csoportjába kerül, mikor bekerül a gyorsítótárba. A csopor- 
tok neve: hash bucket, azaz fasírtosvödör. 
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o Hash buckets 

Amikor egy új kérés kiszolgálása előtt el kell dönteni, hogy 
egy kért elem hol van, rá kell ereszteni a kért adat azono- 
sítójára a hash algoritmust, hogy kiderüljön a hovatarto- 


zása. Ha ez megvan, igen rövid idő alatt eldönthető, hogy 
bent van-e a kiválasztott vödörben, vagy nincs. 


4. felhasználás: hash join 

Ez a felhasználási mód igen hasonlatos a harmadikhoz, 
vagyis gigantikus, ámde rendezetlen halmazokban gyorsít- 
ja a keresést. Ám látom kollégáimat integetni itt a stúdió- 
ban az üvegfalon túlról, hogy túlléptem az időkeretet, így 
most áttérünk az ismertebb hashalgoritmusok elemzésére. 
Ígérem, visszatérek az SOL Server hash joinjaira, de ezt egy 
külön cikkben, a join stratégiák elemzésében teszem meg 
- valamikor még ebben az évben. 


Elterjedt hashalgoritmusok 

Az alábbiakban néhány különösen elterjedt hashalgoritmus 
működéséről lebbentem le a fátylat. Hihetetlen, de igaz: 
egy jól megtervezett hashalgoritmus egyszerre primitív 
(gyors) és hatékony. Úgy darál, hogy azt senki utána nem 
csinálja! Ez alól talán csak a LanMan kivétel, mely kizáró- 
lag primitív, de egyáltalán nem hatékony. 


LanMan és NTLM 

Kezdjük a sort a sokat szenvedett LanMan, NTLM párossal. 
Párban, kézenfogva járnak a hálózaton (amíg le nem tiltjuk 
őket), elvileg azért, hogy a hitelesítő kiszolgáló kiválaszt- 
hassa az általa ismert hash-t a bejelentkezésből. Ennek az 
a gyakorlati hackerhaszna, hogy a két, egyenként is gyen- 
ge hash egymást árulja el. Ami nem deríthető ki az egyik- 
ből, megmondja a másik és vica versa. A security by obscu- 
rity tökéletes mintapéldányai ők, akik az algoritmus nap- 
világra kerülésével pillanatok alatt nevetségessé váltak. 
Hogy miért? Mert például a nagy hekkelésben beléjük fej- 
lesztődött egy olyan megoldás, ami ügyesen meglékeli a 
hosszú jelszavak által elérhető biztonságnövekedést azál- 
tal, hogy azokat hétkarakteres csoportokra bontja, s külön- 
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külön végzi el a , titkosítást" (a jelszavak maximális hossza 
14 karakter). Így nem meglepő, hogy egy nyolckarakteres 
jelszó semmivel sem biztonságosabb egy hétkarakteresnél, 
hisz a nyolcadik karakter önálló csoportot alkot, külön ,,tit- 
kosul". Ez meg is magyarázza, hogy a LOphtCrack miért 
olyan fura módon fejti meg a jelszavakat, hogy a vége (a 
hetediken túli rész) már rég megvan, az elejével meg még 
mindig 4 óra munkája van hátra. Szintén nem válik dicső- 
ségére e párosnak, hogy az üres jelszavak semmilyen el- 
lenállást sem tanúsítanak, azonnal , visszafejthetők". Ez pe- 
dig annak a következménye, hogy az öregebbik, a LanMan 
a hash lefuttatása előtt minden jelszót 14 karakteresre ke- 
rekít, legyen az bármilyen hosszú. A LanMan lépsei: 
8 a jelszó nagybetűssé konvertálása (sic!) 
-8 kiegészítése szóközökkel, hogy 14 bájtos legyen 
8 a 14 bájtból 2 db DES kulcs készül (14 bájt - 112 bit - 
2"56 bit) 
"8 akét 56 bites DES kulccsal titkosítjuk a 
0x4B47532140232425 , mágikus" számot (sic!) 
"8 az eredmény 2"8 bájtnyi, összesen 16 bájtos ,hash" 
Hogy ez mitől hash, amikor DES? Ne kérdezzék. Security by 
obscurity és pont. 
A fenti lépéssorozat folyománya, hogy ha a jelszó rövidebb, 
mint 8 karakter, a 7-14 bájtok mindig OXAAD3B435B51404EE- 
re ,hesselődnek". Az üres jelszó ,titkosított" változata 
megegyezik hét darab szóköz titkosított kimenetével. 
A LanMan hash tehát ,megadja" Claudia Sniffernek a jel- 
szavak nagybetűs változatát, s ezeket rápróbálva az NTLM- 
re (MD4 alapú), pillanatok alatt megvan az eredeti jelszó. 
Mindenki sürgősen térjen át Windows 2000-re, vagy 
legalábbis tiltsa le a LanMant, s az NTLM-ből is az új vál- 
tozatot (NTLMv2) használja! 
(Az NTLMv2 egyelőre állja az ostromot (MD4 helyett HMAC- 
MD5-öt használ), beállításáról terjedelmes cikkünk jelent 
meg tavaly novemberben. ) 


MD5 (Message Digest 5) 

Az MD5 algoritmus társai közül gyorsaságával és hatékonysá- 
gával tűnik ki (bár egy fokkal lassabb feltört elődjénél, az 
MD4-nél). Az RSA társaság készítette (Rivest, Shamir, 
Adleman matematikusok) . Ha elárulom a működését (és miért 
ne tenném, RFC 1321, a [3] címen olvasható, s még C nyelvű 
forráskód is van hozzá) nem fogjuk elhinni, hogy ez így bár- 
mire is jó, s valóban egyedi értékeket ont magából. A futási 
sebesség megköveteli, hogy ne legyen benne semmi rendkí- 
vüli. Van négy ,dugattyúja", melyek 32 bites számokon vé- 
geznek primitív, fél órajeles műveleteket, s ezeken mintegy 
áttoljuk a trancsírozandó adatot. (Persze a fél órajeles primi- 
tív függvények nagyon is bonyolult matematika eredményei.) 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
2001. 10. 


16 





17 


WINDOwS 2000 


HASH! 




















0 Az MD5 algoritmus működés közben 


A 32 bites egyszerű műveletek iszonyatos sebességet kölcsö- 
nöznek az algoritmusnak, a négy ,munkahenger" pedig - 
több processzoros rendszerben - a valódi párhuzamos végre- 
hajtás lehetőségét teremti meg. Anélkül, hogy részletezném 
a teljes működést, tekintsük meg a dugattyúk feladatát: 

8 P- F(X,Y,2) - XY v not(X) Z 

"8 0 - G(X,Y,2) - XZ v.Y not(Z) 

"a SZTN tata aze 

"8 S - I(X,Y,2) 5 Y xor (X v not(2)) 

A dinzébtk összevárnak három 32 bites számot, és akkor 
robban a keverék. A figyelmes szemlélődő észreveheti, hogy 
F() nem más, mint bitenkénti if (If X then Y else Z), míg 
H() egy paritásfüggvény a három bemenő adatra. 

A feldolgozás végeredménye mindig egy 128 bites szám. Az 
MD5 (egyelőre) nincs feltörve, azaz még soha senkinek sem 
sikerült két olyan különböző doksit felmutatnia, amelyek- 
nek az MD5 hash-e megegyezett volna. Ez nem is csoda, 
hisz ha a 128 bitet egyszerűen sorszámozásra használnánk, 
segítségével a föld minden négyzetcentiméterére tízezer 
egyedi dokumentum lenne elhelyezhető (lásd még: GUID)! 
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SHA-1 (Secure Hash Algorithm) 

Lapzárta után" (1997-ben :-) érkezett a hír: az MD5 mégis- 
csak rogyadozik: ,MD5 has been recently shown to be vul- 
nerable to collision search attacks [Dobb)]." Kell hát valami 
új, valami megbízhatóbb. ,SHA-1 appears to be a crypto- 
graphically stronger function." (A két idézet a HMAC RFC-ből 
való (RFC 2104, [4] cím), az SHA RFC-je pedig a 3174-es, 
és az [5] címen olvasható). 

Az SHA algoritmus is az MD4 utódjaként született, és bármi- 
lyen bemenő adatra 160 bites outputot szolgáltat. Szerzői 
közt szerepel a Cisco társaság. ,Kéthengeres", de itt már 
nem négy, hanem nyolcvan (80!) függvény dolgozik úgy, 
hogy a hengerekben menet közben cserélünk dugattyút. 


Salt 

A hashalgoritmusok egyik erőssége, hogy ugyanazokon az 
adatokon végrehajtva ugyanazt a kimenetet produkálják. Ez 
néha - különösen titkosítási felhasználáskor - visszafelé 
sülhet el, hisz a gyakran ismételt minták (például az üres 
jelszó hash-e) könnyedén felismerhetővé válnak. Ezt elkerü- 
lendő egyes hash (emlékezzünk: fasírt!) algoritmusok lehe- 
tővé teszik, hogy paraméterezzük őket: ízlés szerit megfű- 
szerezhetjük az outputot. A paraméterezés évszázados öt- 
let, az NTLM challenge/response azonosításnál előszeretet- 
tel használják. A 8 bájtos challenge valójában nem más, 
mint salt, melyet az NTLM algoritmus futása során a jelszó- 
hoz keverünk. Az egyik legismertebb salt a HMAC algorit- 
mus, melyet úgy terveztek, hogy a meglévő és bevált algo- 
ritmusokkal változtatás nélkül együttműködjön. Így jön lét- 
re a HMAC-MD5, HMAC-SHA-1, melyek az eredeti algoritmu- 
sok sózott változatai. A nevekből talán kikövetkeztethető, 
hogy a HMAC előfeldolgozást végez az adatokon, s annak 
kimenetét juttatja el az eredeti MD5, SHA-1 vagy tetszőle- 
ges algoritmushoz. Enkapszuláció. 

A salt a hashalgoritmusok sava-borsa! 


Fóti Marcell 
marcellf-onetacademia.net 
MCSE, MCT, MCDBA, MZ/X 


A cikkben szereplő URL-ek: 


[1] LOPhtCrack 

http:/, nuatstake.com/researetvte3/index. html 
[2] Törőszótárak 

http://wordlists.security-on.. fat/docAoadheni 
[3] Message Digest, MD5, RFC 1321 
http://www.ietf.org/rfc/rfc1321.txt 

[4] Keyed-Hashing for Message Authentication, HMAC, 
RFC 2104 

http://www.ietf.org/rfc/rfc2104.txt 

[5] Secure Hash Algorithm, SHA-1, RFC 3174 
http://www.ietf.org/rfc/rfc3174.txt 
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Szálak 
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dőzítés 


Időzítés és prioritás 

Az előző számban megjelent cikk folytatásaképpen a követ- 
kező oldalakon kicsit részletesebben bemutatjuk a Windows 
NT/2000 végrehajtási szálakat időzítő rendszerét, annak 
szabályait. Cikkünk - az előző részhez hasonlóan - David 
Solomon [1] Barcelonában, a Tech.Ed 2001-en elhangzott 
előadása, valamint ugyanő és Mark Russinovich Inside Mic- 
rosoft Windows 2000 (Third Edition) [2] című könyvének 
aktuális fejezete alapján készült. Ez a könyv egyébként 
ajánlott, sőt, kötelező olvasmány mindenkinek, aki szeret- 
ne komolyabban foglalkozni a Windows lelkivilágával. 
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Egy kis ismétlés 

Foglaljuk össze az előző számban leírtakat: a Windows 
NT/2000 (továbbiakban csak Windows, különös tekintettel 
arra, hogy nem a Windows 9x családról van szó) operációs 
rendszer szinten végrehajtási szálakat futtat. Minden vég- 
rehajtási szál valamilyen processzhez tartozik (egy processz- 
hez akár több is); ezek a processzek képezik a tulajdonkép- 
peni alkalmazásokat. A processz nem más, mint az általa 
birtokolt végrehajtási szálak részére fenntartott adminiszt- 
ratív objektum és közös memóriaterület - a végrehajtási 
szálak időzítésében általában nem játszik szerepet. Kivételt 
képez ez alól a prioritás esete; az induló végrehajtási szá- 
lak kezdetben a szülő processz prioritásértékét öröklik, és a 
felhasználói felületen is csak a processz (és általa az összes 
hozzá tartozó végrehajtási szál) prioritása módosítható. 

A Windows 32 prioritási szintet kezel; a magasabb érték 
magasabb prioritást jelent. A 32 prioritási szint két fő rész- 
le oszlik: az alsó félben (0-15) az úgynevezett dinamikus, 
a felső félben (16-31) pedig az úgynevezett valósidejű 
prioritásértékek találhatók. A 0 prioritásértéket kötelezően 
a Zero Page Thread viseli (lásd a Windows memóriakezelésé- 
ről szóló cikket az előző számban). 
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Dinamikus prioritás (1...15) Valósidejű prioritás (16...31) 
5 A Windows 32 prioritási szintje és a prioritásosztályok 


elhelyezkedése 
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és prioritás 


A fenti ábrán a Windows 32 prioritási szintje mellett a felhasz- 
nálói felületen keresztül is elérhető, úgynevezett , prioritás- 
osztályok" találhatók. A processzek (és rajtuk keresztül a vég- 
rehajtási szálak) prioritását ugyanis mi, a felhasználó is meg- 
határozhatjuk és módosíthatjuk. Futás közben a Task Manager- 
ben jobb gombbal kattintva kiválaszthatjuk a kívánt prioritást. 
; 
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9 Processz prioritásának módosítása futás közben a 
Task Manager segítségével 


Az egyes prioritásosztályok beállítása során a processz az 
előző ábrán látható középértéket kapja (a Normál prioritás 
középértéke például 8). A prioritás indítás előtti beállításá- 
nak egyetlen módja a start parancs, amelynek paraméter- 
ként átadhatjuk a kívánt prioritásosztályt, valahogy így 
(lásd még: start /?): 


start /low notepad.exe 


start /abovenormal notepad.exe 


A processz (figyelem! nem a végrehajtási szál!) aktuális, 
alap (bázis) prioritásosztályát a Task Manager-ben, a Base 
Priority oszlopban láthatjuk, de jobban járunk ha (például) 
a Windows 2000 Support Tools-ból futtatjuk a Process Vie- 
wer-t (pview.exe), mert akkor nemcsak a bázisprioritást, de 
a végrehajtási szálak aktuális (current) prioritásértékeit is 
megleshetjük. A végrehajtási szálak státuszának és prioritá- 
sának másik jó megfigyelőeszköze a Performance Monitor 
(használatát az előző számban már bemutattuk). 


Az operációs rendszer magja (a kernel) valósidejű 
prioritású végrehajtási szálakat futtat. Legyünk óvato- 
sak a valósidejű prioritás használatával, mert előfor- 
dulhat, hogy létfontosságú [I/O végrehajtási szálaktól 
vesszük el a futási időt. Az általa elérhető végrehajtá- 
si szálak prioritását bármelyik felhasználó módosít- 
hatja, egy korlátozással: valósidejű prioritást csak az 
állíthat be, aki rendelkezik az , Increase scheduling 
priority" privilégiummal - ez alapértelmezésben csak 
az Administrators csoportra érvényes. Ha a prioritást 
módosítani próbáló felhasználó ezzel a privilégiummal 
nem rendelkezik, a processz valósidejű helyett , High" 
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(dinamikus) prioritásosztályba kerül. Végül: meg kell 
jegyeznünk, hogy miközben a valósidejű prioritásokról 
beszélünk, a Windows nem igazi valósidejű (real-time) 
operációs rendszer (ld. még: [3]). 


Alap és pillanatnyi prioritás 

Egy végrehajtási szál pillanatnyi prioritásértéke két részből 

áll össze: § 

"0 A végrehajtási szál alapprioritása (base priority). 

"0 A relatív prioritás (priority boost), ami az alapprioritás- 
hoz hozzáadódik, és értéke idővel változhat. 

A priority boost-ról később még lesz szó, de azt már most el- 

mondhatjuk, hogy a valósidejű prioritásértékkel futó végre- 

hajtási szálaknál a rendszer nem használja - ezek pillanatnyi 

prioritásértéke mindig megegyezik az alapprioritással (ezért 

hívják a nem valósidejű prioritásértékeket dinamikus prioritás- 

nak). A végrehajtási szálak futtatásának időzítéséhez az idő- 

zítő (dispatcher) mindig a pillanatnyi prioritást ellenőrzi. 


A dispatcher várakozási sor-adatbázisa 

A végrehajtási szálak időzítését végző komponens, a dis- 
patcher (ami a maga valójában nem is létezik, feladatát ker- 
nelszerte elszórtan található összetevők végzik) minden 
prioritásértékhez egy-egy várakozási sort tart fenn. Ezek- 
ben a várakozási sorokban találhatók a futásra kész (Ready 
állapotú) végrehajtási szálak. A dispatcher adatbázisát a 
következőképpen ábrázolhatjuk: 


Default base priority 
Process Default processor affinity 


Default guantum 


Dispatcher ready gueue 


Process 


Base priority 


Current priority 
Processor affinity 
Ouantum 
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5 A Dispatcher várakozási sor-adatbázisa 


Az ábra bal oldalán láthatók a különböző prioritásértékhez 

rendelt várakozási sorok (Dispatcher ready gueue). Az adat- 

bázis a feldolgozás meggyorsítása érdekében két összegző 
mezőt is tartalmaz: 

"b A Ready summary bitmező valamely bitjének értéke azt 
jelzi, hogy az adott prioritású várakozási sorban talál- 
ható-e futásra kész végrehajtási szál (azaz érdemes-e 
egyáltalán benézni a várakozási sorba). 

"8 Az 3 bitmező pedig processzorokat tartal- 
maz: a bitek értéke az adott processzor szabad (idle) 
állapotát jelzi. Találós kérdés: legfeljebb hány pro- 
cesszort képes használni a jelenlegi legizmosabb Win- 
dows, a Datacenter Server? 

A legfontosabbak mégiscsak a várakozási sorok: amikor a 

Windows a következő nyertes végrehajtási szálat keresi, 
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ezeket a várakozási sorokat ellenőrzi, a legmagasabb prio- 
ritásútól a legalacsonyabbig. Ha egy várakozási sorban ta- 
lálunk futásra kész végrehajtási szálat, ő léphet futó stá- 
tuszba. Ha egy a várakozási sorban egynél több futásra kész 
végrehajtási szál található, a dispatcher igazságos módon 
körbe-körbe adja majd a futási jogot (round-robin). Ne fe- 
ledjük, ez az igazságosság csakis azonos prioritású végre- 
hajtási szálak között érvényes, az alacsonyabb prioritással 
rendelkezőkkel szemben sokkal keményebben viselkedik a 
Windows: amíg magasabb prioritású szál futásra kész, bi- 
zony az alsó házakban semmi sem történik. 

Ennek demonstrálására készítettünk egy kis példaprogra- 
mot (a [4] címről letölthető) : 


BETTTTET SZT zi 
(637 Normal priority process. 





a Harcban a processzorért: a 
két processz nagyjából egy- 
szerre indult, különbség csak a 
prioritásukban van 
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Az ábrán látható tesztalkalmazás egyvalamire képes: számol. 
Teszi ezt addig, amíg a CTRL--C billentyűkombináció lenyo- 
másával meg nem állítjuk. Az st.bat a start parancs segítsé- 
gével gyors egymásutánban kétszer elindítja ugyanazt az al- 
kalmazást, először egy alacsonyabb, majd egy magasabb 
prioritással. Az eredmény önmagáért beszél. Ha kipróbáljuk, 
érdemes megfigyelni, hogy a futásidő eloszlása korántsem si- 
ma: amikor néha végre az alacsonyabb prioritású végrehajtá- 
si szál is szóhoz jut, gyors egymásutánban 15-20 sort ír a ké- 
pernyőre, majd újabb hosszú szünet következik. 

Látható, hogy a magasabb prioritású processz (és az ő egyet- 
len végrehajtási szála) több nagyságrenddel többet futhat, 
mint az alacsonyabb prioritású változat. Az érdekes az, hogy 
ez utóbbi is szóhoz jut néha... nem mond ez ellent a pár sor- 
ral ezelőtt említetteknek? Nos, nem: az alacsonyabb prioritá- 
sú processz nyilván akkor futhatott, amikor a magasabb 
prioritású éppen nem volt futásra kész állapotban (például 
mert I/O műveletre várt), de az is lehet, hogy az operációs 
rendszer mentette meg az ,éhhaláltól" - lásd később. 


A működő rendszer egyik kulcsa a várakozás 

A végrehajtási szálak leggyakoribb állapota a várakozás 
(wait state) . Egy szál sok mindenre várhat: I/O művelet be- 
fejezésére, másik végrehajtási szál lefutására, különféle 
rendszereseményekre, sült galambra (ami tíz másodperc 
múlva érkezik) - ezek mindegyike annyiban hasonló, hogy a 
várakozás során a végrehajtási szál várakozó státuszba lép 
(onnan majd az adott esemény bekövetkeztekor maga a Win- 
dows lépteti vissza). A várakozó státusz pedig nem futásra 
kész státusz, ezért ilyenkor végre feljöhetnek a felszínre az 
addig fuldokló, alacsonyabb prioritású végrehajtási szálak is. 
Van még más eset is, amikor a Windows (a Dispatcher) új- 
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ra kiértékeli, ki lehet a következő futó szál - jusson 

eszünkbe a felsorolás az előző számból: 

B Új végrehajtási szál futásra kész - mert új szál jött létre, 
vagy tért vissza várakozó státuszból 

"0 Az éppen futó végrehajtási szál elhagyja a futó státuszt 
- mert lejárt a számára kijelölt időszelet; mert várakozó ál- 
lapotba lépett, vagy mert végleg befejezte a működését 

"8 Valamelyik végrehajtási szál prioritása megváltozik - ha 
önmaga, vagy akár az operációs rendszer módosítja a 
szál prioritását 

"Ha a futó végrehajtási szál Processor Affinity értéke meg- 
változik 


Priority Boost I/O műveletek után 

A felhasználó felé nyújtott optimális reakcióidők kialakítása 
érdekében a Windows bizonyos esetekben átmenetileg meg- 
növelheti egy-egy végrehajtási szál prioritását. Az I/0 mű- 
veletet , végző" végrehajtási szál elküldi a kérést az eszköz- 
meghajtónak, majd a művelet befejezéséig wait state-be ke- 
rül. Amikor a művelet befejeződik, a szál újra futásra kész 
státuszba kerül, ráadásul a Windows átmenetileg a prioritá- 
sát is megnöveli. Hogy ez a növelés milyen mértékű, azt az 
adott I/O eszköz eszközmeghajtója határozza meg. Az aján- 
lott érték típusonként más és más (videó, lemez, CD-ROM, 
párhuzamos port: 1, hálózat, soros port: 2, billentyűzet, egér: 
6, hang: 8). Ez az érték mindig a szál alapprioritásához adó- 
dik hozzá és az összeg soha nem lépi át a 15-öt (valósidejű 
prioritásnál pedig nincsen boost). A megnövelt prioritás csak 
rövid ideig érvényes, minden guantumegység lejártakor a 
prioritásérték is csökken eggyel, egészen addig, míg a vég- 
rehajtási szál újra el nem éri az alapprioritásértéket. 


Priority Boost az előtérben futó végrehajtási szálnak 

A Windows a wait state-ből visszatérő, előtérben futó vég- 
rehajtási szál prioritását is megnöveli, mégpedig az előző 
számban bemutatott Win32PrioritySeparation registry 
érték alsó két bitjén beállított értékkel (a Ouantum boost- 
nál ez csak egy mutató volt (,,Boost értéke"), ezesetben vi- 
szont maga az érték számít) . Ez az érték a végrehajtási szál 
pillanatnyi prioritásához adódik hozzá. Hasonlóképpen, 
további 2 boost-ot kap minden végrehajtási szál, ami ab- 
lakkezelő üzenetet kap (ablak mozgatása, méretezése, stb). 


Priority Boost az ,éhhalál" (starvation) ellen 

Minden operációs rendszer egyik fő problémája az alábbi: 
tegyük fel, hogy egy 7-es prioritású szál fut; egy 11-es 
prioritású szál egy olyan erőforrásra vár, amit éppen egy 4- 
es prioritású szál birtokol... A számlálós példában láthat- 
tuk, hogy a nagyétkű 7-es miatt a 4-es prioritású szál bi- 
zony nem lesz képes befejezni a munkáját, és elengedni az 
erőforrást - az eredmény az, hogy a 11-es prioritású szál 
is éhenhal. Az ilyen helyzetek elkerülése érdekében a Win- 
dows kernel ,Balance Set Manager" nevű komponense fo- 
lyamatosan ellenőrzi, hogy mely végrehajtási szálak nem 
jutottak szóhoz az elmúlt 300 órajel-intervallumban 
(300x10ms z kb. 3 másodperc) . Ha talál ilyet, a szegény el- 
nyomott végrehajtási szál prioritását 15-re emeli, és dup- 
la Ouantumot ad neki (!/). Ezidő alatt a szál lélegzethez 
juthat. A dupla időszelet lejárta után azonnal minden 
(prioritás) visszatér a régi kerékvágásba. Indítsuk csak el 
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újra a példaprogramocskát! Nem feltűnő, hogy az alacso- 
nyabb prioritású végrehajtási szál kb. három másodpercen- 
ként jut szóhoz? :-) Természetesen ez a módszer sem töké- 
letes, ráadásul a Balance Set Manager (teljesítményokok- 
ból) egyszerre csak 16 elnyomott végrehajtási szálat el- 
lenőriz - de az esetek többségében ez a kis segítség elég 
a patthelyzetek (deadlock) elkerülésére. 


Többprocesszoros rendszerek 
Többprocesszoros rendszerben a végrehajtási szálakhoz úgy- 
nevezett processzor-affinitást rendelhetünk. Ez tulajdon- 
képpen nem más, mint egy maszk, ami meghatározza, hogy 
az adott végrehajtási szál melyik processzor(ok)on futhat, 
és melyeken nem. Még két másik fogalmat kell tisztázni: 
"8 Ideal Processor: a végrehajtási szál létrehozásakor a Win- 
dows véletlenszerűen hozzárendel egy , kedvenc" processzort. 
"2 Last Run Processor: az a processzor, amelyen a végrehaj- 
tási szál utoljára futott. 
Amikor egy végrehajtási szál futásra kész állapotba lép, a 
Windows szabad (idle) processzort keres a számára. Ha meg- 
teheti, a végrehajtási szál ideális processzorát választja; ha az 
nem szabad, a last run processzort; ha pedig az sem szabad, 
akkor a Dispatcher adatbázisból keres egy ráérő példányt. 
Ha nincs szabad processzor, akkor a Windows megkeresi az 
első, a végrehajtási szál által használható processzort, és ha 
azon a végrehajtási szál prioritásánál alacsonyabb prioritá- 
sú szál fut (running) , vagy készül a futásra (standby), akkor 
átveszi annak a helyét (ez a preemption) . Ha a prioritás nem 
elegendő, a Windows nem keres másik processzort a végre- 
hajtási szálnak, hanem azt a várakozó sorba helyezi. 
Amikor egy processzor felszabadul, az egyprocesszoros 
rendszerekkel ellentétben a Windows nem az első futásra 
kész végrehajtási szálat indítja, hanem előbb azt, amelyik 
megfelel az alábbiak valamelyikének: 
0 Utoljára az adott processzoron futott 
8 Az ideális processzora az adott processzor 
"8 Legalább két Ouantum óta futásra kész 
8 24, vagy nagyobb a prioritása 


Végül... 

Szeretnék bemutatni egy, a weben talált tanulságos szimu- 
lációt. Kattintsunk a [5] címre, és elénk tárul egy kétpro- 
cesszoros rendszer (Flash plug-in szükségeltetik), ahol kö- 
vethetjük a három processz négy végrehajtási szálának fu- 
tását. A végrehajtási szálak processzor-affinitást is tartal- 
maznak, a szimulációt a , Clock" feliratú kapcsoló nyomo- 
gatásával léptethetjük. Jó szórakozást! 


Fülöp Miklós 
mick Enetacademia.net 


A cikkben szereplő URL-ek: 
[1] http://www.solsem.com 
[2] http; ESZES TÉS ZEGAL 


[3] http://support.microsoft.com/support/kb/articles/094/2/65.ASP 


[4] http://technet.netacademia.net/download/threading 
[51] http://www.8Ogmultimedia.com/winnt/simulator.htm 
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Sok víz lefolyt a Dunán amióta a Microsoft megtiltotta né- 
pünknek a klónozószoftverek használatát, mondván, hogy a 
kopizott gépek összeakadnak a hálózaton, hisz azonos a 
SID-jük. A gép-SID (Security ID) az adott gép biztonsági 
adatbázisának egyedi azonosítója. Az ott később létreho- 
zott biztonsági objektumok (felhasználók, csoportok) a gép- 
SID alapján, növekvő számsorrendben kapnak egyedi belső 
azonosítót. Erről tanúskodik az alábbi ábra is: világosan 
látszik az objektumok SID-jeinek közös gyökere. Ha a gép- 
SID-ek nem különböznek a hálózat összes gépén, akkor - 
minden emberi számítás szerint - lesznek azonos SID-del 
rendelkező felhasználók, és lesz nemulass!! 
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5 SID-ek a regisztrációs adatbázisban. A kijelölés a 
Guest SID-jén áll 


A fennhangon hirdetett tiltás ellenére a MS maga is elősze- 
retettel klónoz például konferenciáin, ahol egyszerre 500 
gépre kell felhúzni az alkalmazásokkal zsúfolásig teletelepí- 
tett operációs rendszert. Ilyenkor bizony nem mindegy, 
hogy klónozó (Ghost, DriveImage stb.) vagy automatikus te- 
lepítő (unattend.txt vagy RIS) használatát választjuk-e, az 
előbbiek ugyanis egy nagyon fontos dologban lekörözik az 
utóbbi megoldásokat: tudnak multicastolni. Az IP Multicast 
lehetővé teszi, hogy akár 500 gép telepítése esetén is csak 
egyetlenegyszer menjen át a WINNT könyvtár teljes tartal- 
ma a hálózaton - szemben az automatikus telepítésekkel, 
amikor minden géphez egyenként, külön-külön el kell jut- 
tatni ugyanazt az adathalmazt. 

Most mondhatják erre Kedves Klónozó Olvasóim, hogy nincs itt 
ellentmondás, hisz a modern klónozószoftverek lehetővé teszik 
a gépek SID-jeinek utólagos átirkálását. Igen ám, de minek? 
Meggyőző, hibátlan példák igazolják, hogy klónozott, azonos 
SID-del még NT4 Backup Domain Controllerek is elketyegnek, 
nem beszélve a munkaállomásokról. Akkor hogy is van ez? 
Elsőként vizsgáljuk meg, milyen körülmények között lenne 
nemulass", okozna gondot a hálózaton felbukkanó két 
azonos gép-SID. Nyilván akkor, ha találkoznának. Ámde a 





A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
2001. 10. 


SID vita 


Network Monitor tetszőlegesen szorgos használata sem ele- 
gendő ahhoz, hogy gép-SID-eket láthassunk a kábelen, 
azon egyszerű oknál fogva, hogy azok sohasem hagyják el 
a gazdagépet azt az esetet kivéve, amikor a merevlemezt 
átcipeljük egyik gépből a másikba. Ennélfogva össze sem 
ütközhetnek. Pont. Cikk vége...? 

Ha Önök most azt mondják, hogy nincs igazam, mert láttak 
már Computer Accountot a tartományvezérlőkön, akkor er- 
re azt mondom: az nem a gép eredeti, belső azonosítója, 
hanem egy, a tartományvezérlő által generált új felhaszná- 
ló, új SID-del! Minden új felhasználó új SID-et kap. A 
Computer Account nem ,átmegy", hanem ott születik a tar- 
tományvezérlőn a munkaállomás csatlakozásának pillanatá- 
ban. Bizonyítékként szolgálhat, hogy Computer Accountot 
kézzel is létrehozhatunk (akár egy olyan gép számára, mely 
még olyan messze áll a tartományi csatlakozástól, hogy hun- 
garocel és hullámpapír fogságában sínylődik egy raktárban). 
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Computer name: 
(Munkaállomás 


Computer name (preWindows 2000 
MUNKAÁLLOMÁS 


The following user or group can join this computer to a domain, 
User or group: 


fpefautt Domain Admns Change... 


TT Allow pre:windows 2000 computers to use this account 
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5 Computer Account létrehozása a címtárban 


Az azonos SID-del rendelkezők egy személynek számítanak? 
Egy picit most már elárultam az igazságot, így a babonások 
második érve előtt sem hullunk a porba: azt mondják, hogy 
ha két gépen azonos két felhasználó SID-je, akkor még ab- 
ban az esetben is hozzáférnek a másik, sziámi iker adatai- 
hoz, ha annak teljesen más a bejelentkezési neve és jelsza- 
va. Hümm. Mondjak ellenpéldát, vagy nem is kell magyaráz- 
nom? Két ellenérvem is van: 

1. A felhasználók azonosítása névijelszó alapján történik. 
Az azonosítás pillanatában senkit sem érdekel a júzer SID- 
je. Azonosítás után meg úgyis annak a nevében dolgozhat, 
akinek tudta nevét és jelszavát, a kör bezárult. 

2. Vannak a hálózaton azonos SID-ek. Minden telepített 
Windowsban tejlesen azonos az Authenticated Users, az 
Everyone, az Administrators és még sok egyéb csoport SID- 
je. Ezeket Well Known (közismert) SID-eknek hívják, és az 
[1] címen olvashatunk róluk részletesebben. Néhány példa: 
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Administrator: S-1-5-domain/machine SID-500 
S-1-5-domain/machine SID-501 


Ss-1-5-32-544 


Guest: 


Administrators csoport: 


De ugye nem találkoztunk még olyan esettel, hogy a Well- 
Known SID-ek miatt automatikusan be tudunk lépni rend- 
szergazdaként a hálózat összes gépén? Pedig minden gépen 
tagja minden rendszergazda a mindig azonos SID-ű 
Administratos csoportnak. Hiába azonos a SID, mivel az a 
kutyát nem érdekli. Mindenki név-ijelszó párossal fér hozzá 
a hálózati erőforrásokhoz - már ha tudja a jelszót. Ha nem 
tudja, megsütheti a Well Known és ráadásul azonos SID-jét! 
De térjünk vissza a Computer Accounthoz. 


Mi is a Computer Account? 

Egy név-jelszó páros, mellyel a bootolást végző munkaállomás 
hitelesíti önmagát a tartományvezérlők előtt. Ezt a két ada- 
tot (névajelszó) mindegyik munkaállomás megjegyzi magá- 
nak, hogy minden rendszerindításkor sikerrel vegye a beje- 
lentkezési akadályt. Megjegyzi? Ugyan! Felírja magának, ide: 


ee Wew Securty Options Window Help -l8l 2] 
EI HKEY. LOCAL MACHINE z 
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HO Cache 

FE Policy 

LE Secrets 
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HO CupdTime 


E Cunval 
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E SecDesc 
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5 A munkaállomás ide ,,rejti" a saját tartományi nevét 
és jelszavát. A júzer meg kiragasztja a magáét a moni- 
torra. Melyik a veszedelmesebb? 


Sikeres név (gépnév$) és jelszó megadása után az adott 
masina belép a tartományba, és úgy is marad kikapcsolá- 
sig. Mindegy, hogy a júzerek be tudnak-e jelentkezni a tar- 
tományba - ő bent van és kész. 


Megoldódik egy rejtély 

Minden rendszergazda gépe egységesen zavaros. Van rajta 
vagy hat Windows, ebből négy munkaállomás, kettő kiszol- 
gáló. Ha el akarjuk kerülni, hogy ide-oda bootolgatásunk 
miatt a Browse lista (Hálózatok, Network Neigborhood 
ikon) tele legyen a mi hat operációs rendszerünk kikap- 
csolt zombijaival, egyszerűen mind a hatnak ugyanazt a 
gépnevet adjuk. Úgysem futnak egyszerre! 

Azonban amikor be akarjuk léptetni a tartományba mind a ha- 
tot, azt tapasztaljuk, hogy egyszerre csak egy tud bemenni. 
Miért? Mert a legelső, mely csatlakozik, (és amely miatt létre- 
jön a Computer Account) , azonnal és ravasz módon meg is vál- 
toztatja a hozzátartozó jelszót, hogy ne legyen más, aki be tud- 
jon lépni ugyanezzel a gépnév$ login névvel. Hát nem is tud! A 
maradék öt Windowsunk hoppon marad: ugyanolyan névvel nem 
tudnak taggá válni ugyanabban a tartományban - sajnos. 
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Ha jobban szemügyre vesszük a munkaállomás és a tarto- 

mány kapcsolatát, észrevehetünk egy-két hasonlóságot a 

megbízotti (trust) kapcsolatokkal, hiszen: 

"8 A tartományi felhasználók akár lokálisan, akár megosztá- 
sokon keresztül ténykedhetnek a munkaállomáson, 
mert az elfogadja a DC-k hitelesítését. Ha a DC azt 
mondja, hogy Bubuka az Bubuka, akkor ezt a munkaál- 
lomás nem kérdőjelezi meg, hisz neki (we trust in dc). 

8 A munkaállomás lekérdezheti a DC-k felhasználói adatbá- 
zisát (bizalom, bizalom) , hogy abból tetszésünk szerint 
válogathassunk pasasokat és csoportokat a jogosult- 
ságlistákba. 

"8 A tartományi globális rendszergazdák a munkaállomáson 
is erős legények: belehullott a Domain Admins csoport 
a lokális Administrators csoportba. 

Ez biza trust, még ha kicsit butított is. Miben különbözik 

az Active Directory tartományok közötti meghatalmazotti 

viszonytól? Hát szinte mindenben: 

"8 Nem automatikusan jött létre (kézzel be kellett terelnünk 
a gépet a tartományba). 

8 Nem kétirányú (a munkaállomás lokális felhasználóiban 
és csoportjaiban nem bízik meg a tartomány). 

"8 Nem tranzitív (a munkaállomások nem fűzhetők fel 
minitrust-láncba). 

"8 A munkaállomás nem léphet nászra másik munkaállomás 
sal a biztonsági adatbázis közös felnevelésére (ahogy 
az igazi DC-k teszik). 

De ezzel a különbségek végére is értünk. Ki kell mondanunk, 

hogy a Windows NT Workstation és a Windows 2000 

Professional olyan TARTOMÁNYVEZÉRLŐ (!), melynek kapcso- 

latfelvételi képességei drasztikusan le vannak korlátozva 

ugyan, de attól még a DC az DC! A hercegkisasszonyt is egy- 
ből felismerjük a dunnája alá rejtett borsószem révén, a mun- 
kaállomások poros fedőrétege alatt is megcsillan a sárarany. 


Akkor talán értjük a trustokat is? 

Két tartomány között a meghatalmazotti viszony nem más, 
mint bootoláskor egymáshoz történő kölcsönös bejelentke- 
zés egy, a Computer Accounthoz kísértetiesen hasonló 
fiók, az Interdomain Trust Account segítségével. Ennek 
jelszavát éppolyan formában (a kéménybe van felírva ko- 
rommal) rejtegetik a DC-k, mint ahogy kicsi munkaállomás 
feljegyzi a saját Computer Accountjához tartozót. 
Előfordulhat, hogy mégis gondot okoz a közös SID: ha van 
olyan alkalmazás, ami épít arra, hogy a gépek SID-je 
különböző - hiszen definíció szerint az, végülis megteheti 
- no akkor az az alkalmazás skizofrén állapotba kerül. De 
ha óvatosak vagyunk, mindez elkerülhető. 


Fóti Marcell 
marcellf(onetacademia.net 


A cikkben szereplő URL-ek: 


[1] Well Known Security Identifiers — k 


http://support.microsoft.com/support/kb/articles/0243/3/30.ASP 
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avagy jó-e a notice and take down eljárás? 

A notice and take down eljárás az Internetes önszabályozás 
keretében alakult ki, mára azonban ez a megoldás egyes jog- 
szabályokban is helyet kapott. Az eljárás lényege az, hogy ab- 
ban az esetben, ha egy adott oldalon jogsértő tartalom jele- 
nik meg, a tartalom szolgáltatójának személyétől függetlenül 
a panaszt, és az eltávolítás iránti kérelmet az Internet- 
szolgáltatóhoz (ISP-hez) kell eljuttatni, aki ideiglenesen meg- 
akadályozza a sérelmes információhoz való hozzáférést, vagy 
gondoskodik annak ideiglenes eltávolításáról. Az ISP egyide- 
jűleg értesíti a tartalom szolgáltatóját a beérkezett kérelem- 
ről, aki rendelkezésre álló, általában néhány napos határidőn 
belül tiltakozhat a hozzáférés letiltása vagy az eltávolítás el- 
len. Ez esetben az ISP az információt visszahelyezi, illetve a 
hozzáférést helyreállítja. Amennyiben a tartalomszolgáltató 
ilyen tiltakozást nem jelent be, a sérelmes információt végle- 
gesen eltávolítják. Ellenkező esetben annak, aki azt sérelmes- 
nek találja, marad a hagyományos bírói fórum arra, hogy ott 
intézkedést kérjen a jogsértő állapot megszüntetésére, és kár- 
térítésre perelje a tartalom szolgáltatóját. 

Az eljárást kitalálók lényegében két legyet akartak egy csa- 
pásra ütni: gyors megoldást kínálni jogsértő tartalom ese- 
tén, és ennél sokkal lényegesebb: az Internetszolgáltatót 
mentesíteni mindenfajta felelősség alól. 

Az önszabályozás keretében elterjedt megoldás azonban 
úgy működik, ha az alkalmazási terület nem korlátlan, arra 
nem kap bárki, bármilyen kérdésben felhatalmazást. 
Jellemzően a szerzői jog területén vált be, és nyújt haté- 
kony jogvédelmet azoknak, akiknek szerzői művét felhatal- 
mazás nélkül helyezik el a hálón. 

Az Internet önszabályozásának megfelelő példája a finn megol- 
dás, ahol is a Finnországban működő szerzői jogvédő, az 
ARTISJUS ottani partnere, és a hangfelvételelőállítók finnor- 
szági közös jogkezelő szervezete állapodott meg az egyik leg- 
nagyobb Internetszolgáltatóval abban, hogy szerzői jogot sér- 
tő tartalomra vonatkozó értesítésük esetén a szolgáltató a tar- 
talmat az oldalról eltávolítja. A szolgáltató további kötelezett- 
séget is vállalt a tartalom szolgáltatójának azonosítására, ezzel 
elősegítve a későbbi felelősségrevonást. A rendszer nyilvánva- 
lóan hatékonyan tud működni, hiszen leginkább a monopol- 
helyzetben lévő közös jogkezelő szervezet lehet alkalmas arra, 
hogy az adott mű vonatkozásában elbírálja, rendelkezik-e az 
azt a hálóra helyező valamilyen felhasználási joggal vagy sem. 
Így tehát az e szervezettől érkező jelzés minden bizonnyal 
megalapozott lehet, hiszen maga a szervezet is arra vállalt kö- 
telezettséget, hogy tartalomeltávolítását csak alapos indokkal 
kérik. Az Internetszolgáltató önkéntes kötelezettségvállalása 
hátterében pedig az áll, hogy cserébe a közreműködéséért, a 
közös jogkezelő szervezetek garantálták, hogy nem kezdemé- 
nyezik olyan jogszabály megalkotását, amely az Internet- 
szolgáltató felelősségének megállapításáról szólna olyan tarta- 
lomért, amelyre nyilvánvalóan nem gyakorolt hatást. 
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Hatékony 


megoldás a jogsértő 
tartalommal szemben 


A notice and take down eljárás törvényi szintre emelése az 
Amerikai Egyesült Államok jogalkotásában, a Digital 
Millenium Copyright Act, azaz a Digitális szerzői jogi tör- 
vény keretében történt meg. Amint azt a törvény címe is 
sugallja, itt is a szerzői jogi jogsértésekre redukálta a jog- 
alkotó az eljárás alkalmazhatóságát, tehát panaszt csak ak- 
kor tehet bárki, ha szerzői mű jogosulatlan felhasználását 
tapasztalja a hálón. A kérelmezőnek az értesítésben azo- 
nosítania kell a tartalmat, annak megtalálási helyét, és 
olyan információkat kell szolgáltatnia, amelyek a jogsértés 
tényét valószínűsítik. A kérelmezőnek továbbá nyilatkoznia 
kell arról is, hogy jóhiszeműen cselekszik. A kérelemre az 
Internetszolgáltató köteles a megjelölt tartalmat tíz napra 
eltávolítani, és egyidejűleg erről a tartalomszolgáltatót ér- 
tesíteni. A tartalomszolgáltató köteles haladéktalanul vála- 
szolni az értesítésre. Amennyiben válaszában a jogsértést 
elismeri, vagy 10 nap alatt nem válaszol, úgy a tartalom el- 
távolítása végleges marad. Ellenkező esetben, vagyis ha a 
jogsértés tényét a tartalom szolgáltatója vitatja, a sérelme- 
zett tartalom újra hozzáférhetővé válik, kivéve, ha a kérel- 
mező igazolja, hogy bírósági eljárást kezdeményezett. Ez 
esetben az eljárás jogerős lezárásáig a kifogásolt tartalom 
továbbra sem válik hozzáférhetővé az adott tárhelyen. 

A szolgáltató együttműködését e jogszabályban is a felelősség 
alóli mentesülés garantálja, hiszen ha az Internetszolgáltató- 
nak nem volt tudomása a jogsértő tartalomról, illetve azt az ér- 
tesítést követően onnan haladéktalanul eltávolítja, vele szem- 
ben kártérítési igénnyel nem lehet fellépni. 

Mint látjuk, a notice and take down eljárás azért működik, 
mert az Internetszolgáltató számára megnyugtató megoldást 
ad, ha jól körülhatárolt körben, alaposan valószínűsíthető 
jogsértések esetén eleget téve a jelzésnek eltávolítja a tar- 
talmat, és ezzel mentesül attól, hogy esetleg olyan cselek- 
ményért kelljen kártérítési vagy akár büntetőjogi felelősséget 
is vállalnia, amelyre tényleges befolyással nem rendelkezett. 
Abban az esetben azonban, ha az eljárást korlátlanul, bármely 
tartalom vonatkozásában és bárki számára alkalmazhatóvá 
tesszük, fennáll annak a veszélye, hogy a semmire sem vezető 
automatizmussal kiváló lehetőséget teremtünk arra, hogy egye- 
sek jogaikat visszaélésszerűen gyakorolják. 


Sajnos a magyar Országgyűlés előtt lévő, az elektroni- 
kus kereskedelemről és az információs társadalmi szol- 
gáltatásokról hangzatos nevet viselő törvény tervezete 
pontosan ezt a megoldást tartalmazza! 


Dr. Mayer Erika 
Nádas 8 Mayer Ügyvédi Iroda 
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ISA Server 
(IV. rész) 


Packet Filtering 
A csomagszűrés érvényesíthető mind a befelé jövő, mind a ki- 
felé irányuló kérésekre. A kifelé irányuló kéréseknél felfoghat- 
juk úgy is, hogy ez az utolsó védelmi vonal, vagyis ha a kérést 
átengedi egy protokollszabály (protocol rule) és egy webhelyre 
és -tartalomra vonatkozó szabály (site and content rule) , még 
mindig blokkolhatja egy tiltó csomagszűrő. Például: 
0 Protocol rule: a ,web users" csoportnak engedélyezi a 
HTTP elérést 
Site and Content rule: minden webhelyhez engedélyezi 
a hozzáférést a ,web users" csoportnak 
-0 IP Packet Filter: blokkolja a hozzáférést a 
110.110.110.100 IP címhez 
Ez a szabályrendszer a ,web users" csoportnak minden HTTP 
hozzáférést engedélyez, kivéve a 110.110.110.100 IP című 
webhelyhez - vagyis a tiltó csomagszűrő szabály elsőbbséget 
élvez az egyéb szabályokkal szemben. Ez különösen akkor le- 
het hasznos, amikor gyorsan kell megoldanunk egy biztonsági 
problémát. Egy adott hely elérésének letiltása könnyen meg- 
valósítható a megfelelő csomagszűrő szabály létrehozásával. 
Emellett a csomagszűrési eljárást arra is használjuk, hogy az 
ISA Server felé tartó, illetve a tőle jövő kapcsolatokat szabá- 
lyozzuk. Például ezzel biztosíthatjuk, hogy az ISA Server ne vá- 
laszoljon az ICMP echo (ping) kérésekre, amivel megakadályoz- 
zuk, hogy egy egyszerű pingeléssel bárki kideríthesse létezését. 
A csomagszűrőket használjuk arra is, hogy a DMZ-hez való 
hozzáférést szabályozzuk, ha a DMZ-t egy háromlábú ISA fel- 
használásával alakítjuk ki. Bár sokak szerint a DMZ kialakítá- 
sára nem ez a legjobb módszer, biztos vagyok benne, hogy - 
ha másért nem is, hát a költségek miatt - sokan ilyen rend- 
szert építenek ki (erről természetesen szó lesz a későbbiekben, 
de addig is érdemes lehet megnézni az ISA súgóját. Keressük 
a következőt: three-homed perimeter network configuration) . 
A csomagszűrési eljárás tehát minden esetben megvalósítja 
ezeket a szabályozásokat, és engedélyezi vagy tiltja a kapcso- 
latokat. Ne feledjük azonban, hogy mint minden csomagszűrés, 
ez is ,szűklátókörű", vagyis viszonylag kevés adattal dolgozik. 
Háromféle csomagszűrést valósíthatunk meg. Az első a kül- 
ső hálózat felől az ISA Server-re érkező kéréseket szabá- 
lyozza. Hacsak nincs külön megengedve (csomagszűrő vagy 
közzétételi szabály), ezek a kapcsolatok tiltottak. A máso- 
dik a külvilág számára biztosít hozzáférést az ISA Serveren 
futó szolgáltatásokhoz. Például, ha egy kívülről elérhető 
webkiszolgálót szeretnénk futtatni az ISA-n, meg kell nyit- 
nunk a 80-as portot egy csomagszűrő szabállyal (azért ha 
lehetséges, a webkiszolgálót helyezzük inkább a DMZ-be!!!). 
És végül létrehozunk egy olyan szabályt is, amely a fenti 
példának megfelelően a csomagszűrő a külső hálózat eléré- 
sét fogja korlátozni, mondjuk egy olyan webhelyét, amely- 
ről tudjuk, hogy káros kódot tartalmaz. 
A csomagszűrést a protokolltípus (például TCP, UDP) , a port- 
számok (például 25, vagyis az SMTP port), a helyi és a távo- 
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BIZTONSÁG 


li számítógép IP címének megadásával definiáljuk. A távoli 
számítógép azt/azokat a külső hálózaton levő számítógé- 
pe(ke)t jelenti, amelyekre a szabály érvényesül. A helyi szá- 
mítógép jelentheti magát az ISA Server-t, vagy (háromlábú 
ISA esetén) egy DMZ-ben levő gépet, amire a szabály érvé- 
nyesül. Az IP csomagszűrés statikus, egy adott porton ke- 
resztül folytatott kommunikáció vagy mindig tiltva, vagy 
mindig engedélyezve van. A megengedő szűrők átengedik a 
bennük definiált (adott portra irányuló) forgalmat. A tiltó 
(blokkoló) szűrők pedig mindig megakadályozzák, hogy az 
adott csomagok áthaladjanak az ISA Server-en. 

A következőkben bemutatjuk egy csomagszűrő szabály lét- 
rehozását. Ezeket a beállításokat az adott tömb neve alatt 
megtalálható access policy/IP packet filters alatt a ,Create 
a new packet filter"-re kattintva (1. ábra) érhetjük el. Je- 
len példánkban a 110.110.110.100 IP cím felé irányuló 
összes kérés blokkolását mutatjuk be. 
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5 A csomagszűrők beállításainak helye 


Az első párbeszédablakban névvel láthatjuk el szabályunkat. A 
áttekinthetőség fenntartása érdekében alakítsunk ki valamilyen 
szabványos" elnevezési mintát, és a későbbiekben is ezt alkal- 
mazzuk. Javaslat: a név tartalmazza a szűrő által végrehajtott 
cselekvést (allow/block), és a főbb adatokat (például IP cím). 
A varázsló következő lépésénél megadhatjuk, hogy ez a sza- 
bály csak egy adott ISA Server-en, vagy az egész tömbön ér- 
vényesüljön. Erre nagyon figyeljünk! A későbbiek során jó tud- 
ni, hogy melyik ISA Serveren milyen szabályok is vannak! Vá- 
lasszuk most az ALL ISA Server computers in the array opciót. 





Servers 
This P packet tet c retlor tte serverz jou select 


Setthisíiter loc 
7. ANISA Server computert in the aray 


€ Ontythés server 





5 A szabályt érvényesítő tűzfalak kiválasztása 
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A következő lépésben kiválaszthatjuk a csomagszűrő típu- 

sát: allow vagy block. Válasszuk a block-ot. 

Ezután választhatjuk ki a protokollt. Mivel jelen példánkban 

az adott IP címhez minden hozzáférést le akarunk tiltani, 

válasszuk az egyéni (Custom) opciót. (Az előre definiált 

(predefined) opció választásával egy elég bőséges listából 

választhatnánk, ami csomagszűrőnk működését a kiválasz- 

tott protokollokra korlátozná.) 

Ezután kiválaszthatjuk az egyénileg megadott szűrőnk típu- 

sát. Lássuk miből választhatunk! 

"8 Protokoll típusa (IP Protocol): például TCP, UDP 

"8 ArKkapcsolat iránya (Direction): például befelé (incoming) 
vagy kifelé (outgoing) irányuló 

8 Portszámok 

Példánk kedvéért válasszuk az Any-t az IP protocol-nál, és a 

Both-t (mindkét irány) a Direction-nál. Így kikényszerítjük, 

hogy az adott IP címhez minden hozzáférés tiltva legyen. 












New IP Packet Fiter Wizard 21 
Filter Settings a 
Speoly the protocol used, communization direction. and other titer-specihic 
information. 8 





Select settings for this IP packet filter. 


IP protocck Number 
SETEHZHKNEEBEÉN ESSEN -] [deze 
Direction 

Both . 
Locd port: Port rumber 

[GE ZZRERSETSET E] (ő [SES 
Romoto port: Port rumbot: 
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5 A protokoll megadása 


A szűrést az ISA Server külső címén érvényesítjük. Vegyük ész- 
re azt is, hogy ezen a lapon a harmadik pontban adhatnánk 
meg egy a DMZ-ben levő számítógépre érvényesülő szűrést. 





New IP Packet Fíter Wizard XI 
Local Computer "3 
Select thelP address to uhichthe I? packet filter ís appíed. 


Applythis packet filter to: 


C DefautiP addresses lor ezch external interface on the ISA Server computer 


7 This ISA corvor oxtamal IP addrose: VA 14055 10 


€ This computer (cn the petimetet network). 





et [7] event [/ 





5 Csomagszűrés alkalmazása a külső lábon 


Végül megadjuk, hogy szabályunk mely távoli számítógépre 
érvényesüljön. 
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New IP Packet Fiter Wizard 





Renote Computerz 
Select the remcte ccmpulers to which the IP packet fiter is applied. 


ME 





Apply this peckei filet to: 


€ Állremote computer: 


110 . 110 . 110 , 100 


(Only this rometo cempulor: 





5 A távoli számítógép megadása 


Van néhány dolog, amit érdemes tudni, ha alkalmazni akar- 
juk a csomagszűrést (Hát már hogyne akarnánk!) . 

Először is az ISA Server bővítményei befolyásolhatják a cso- 
magszűrés jellemzőit. Például ha az ISA Serverben megtalál- 
ható H.323 szűrő működik, az 1720-as számú port nyitva 
lesz, függetlenül a csomagszűrési beállításoktól. Vagyis ha 
nincs szükségünk a H.323 conferencing támogatásra, kap- 
csoljuk ki a H.323 szűrőt. A közzétételi szabályoknak (pub- 
lishing rules) hasonló hatásai lehetnek. Ha elég elővigyáza- 
tosak vagyunk, és biztosítani akarjuk, hogy a csomagszűrő 
szabályaink a lehető legszigorúbbak legyenek, , támadjuk 
meg" az ISA Server-t a külső hálózat irányából egy port 
scannerrel, így láthatjuk, hogy mely portok vannak nyitva az 
ISA-n (A port scanner nem okoz kárt, csak megnézi, melyek a 
nyitott portok. Használjuk bátran! Port scannerből több tuca- 
tot találhatunk az Interneten, íme egy példa: nmap.) 

Az ISA csomagszűrése képes az IP forgalom széttördelt ré- 
szeinek (fragment) szűrésére. Ezek a töredékek nem káro- 
sak, hanem arra szolgálnak, hogy olyan adatok is átvihetők 
legyenek, melyek túl nagyok ahhoz, hogy egyetlen csomag- 
ba beleférjenek. A ,hekkerek" oly módon használták/hasz- 
nálják támadások kivitelezésekor ezt az eljárást, hogy olyan 
csomagokat hoznak létre, melyek első látásra ártalmatla- 
nok, de összerakásuk után már kárt okozhatnak. Ennek a 
funkciónak a bekapcsolása erősen ajánlott. 

Az utolsó fontos dolog, amit szeretnék megemlíteni, hogy 
az ISA képes az olyan csomagok szűrésére, aminél az IP 
options flag be van billentve. Az IP optionst is használják 
néha a ,hekkerek". Így lehet például beállítani a source 
routing-ot, vagyis azt, hogy a forrásnál határozzák meg, 
hogy milyen útvonalon haladjon a csomag. Ennek a funk- 
ciónak a használata is javasolt. 

A fenti beállítások elvégzéséhez navigáljunk az IP Packet 
Filters-hez, jobb klatty, majd válasszuk a Properties-t, 
ezután pedig a Packet Filters fület. 
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General . Facket Fiters ] Intrusion Detection ] PPTP ] 


Use this page lo configure packet flter propeties. 


[7 Enabie fiterng ot IP iragments 


[7 Enable fitering P opions 


TT Log packets Írom "Allow fiters 





5 IP fragments és IP Options 


Jónéhány megengedő csomagszűrés előre definiált az ISA 
Server-ben. Ezek a ,konzerv" szűrők a telepítés végén en- 
gedélyeződnek. Lássuk mik is ezek: 

8 DNS Lookup. Ez teszi lehetővé, hogy az ISA Server 
elérje a DNS kiszolgálókat, a belső (például webező) ügy- 
felek kérései alapján. Ez a szabály mindenképpen szüksé- 
ges, ha a névfeloldás ily módon történik. Természetesen a 
névfeloldást elvégezheti egy a belső hálózaton, vagy DMZ- 
ben található, megfelelően beállított DNS kiszolgáló is. 
ICMP szabályok: Ezek a szabályok engedélyezik az 
Internet Control Message Protocol (ICMP) csomagok 
ISA Server és külső hálózat közti küldését és fogadását. 
E csomagok biztosítják például a flow controlt. (ICMP 
Redirect, Source Ouench, Time Exceeded stb. Lásd NetMon 
sorozat.) Az alapértelmezett szabályok elég ártalmatlanok, 
például nem engedik meg, hogy az ISA Server válaszoljon 
a pingekre, vagyis akik így keresnek lehetséges célponto- 
kat, pingeléssel nem fogják megtalálni ISA Serverünket. 
Mivel nem túl megengedőek, a megszokottól eltérően itt 
most meghagyhatjuk az alapértelmezett szabályokat. 


b 


Behatolásészlelés (Intrusion Detection) 

Az ISA Server tartalmaz alapvető behatolás-észlelő funkció- 
kat is. Az Intrusion Detection beállítások az MMC-ben két 
részre vannak osztva, a beállítások egyik fele az IP Packet 
Filters alatt érhető el, a másik fele pedig az Extensions alatt. 
Izgalmas nevük ellenére (Land Attack stb.) ezek sajnos mind 
jólismert, és ezer éve nem használt támadástípusok. Ennek 
ellenére érdemes megismerkednünk velük, sőt bekapcsolni 
őket, mert a legostobább script kiddyk hébe-hóba lefuttat- 
nak egy-egy ősi támadást is. Nehogy ilyenbe haljunk bele! 
A packet filters alatt beállítható behatolásészlelő funkciók 
alapértelmezésben nincsenek engedélyezve. Először navi- 
gáljunk a Packet Filters-hez, varázsoljuk elő a Properties 
lapot, és keressük meg a General fület. Ezután billentsük 
be az Enable Intrusion detection kapcsolót. Ennek előfel- 
tétele, hogy a packet filtering is engedélyezve legyen. 
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MESE 
General ] Packet Fitess ] intrusion Detection ] PPTP ] 


öm 


Use tis page to cortrol packet routng and packet 
totirg prcporties. 


[7 Enzble packet fdteing 


7. Enzble latruson detection 


I EnzblelP routing 





5 A behatolásészlelés engedélyezése 


A behatolásészlelés további ismertetése előtt megemlíteném, 
hogy ebben a párbeszédablakban található az , Enable IP rout- 
ing" opció is. Erre most nincs szükségünk, tehát ne kapcsoljuk 
be. Kész, kiveséztük ezt a bonyolult ablakot, mehetünk tovább. 
Nem kell nagyon messzire mennünk, csak két fülnyit jobb- 
ra. Ez az Intrusion Detection fül, itt folytathatjuk a beha- 
tolásészlelés beállítását. A kis jelölőnégyzetek kipipálásá- 
val engedélyezzük a felsorolt támadástípusok észlelését: 


Port scan attack 

Ez a riasztás arról értesít, hogy kísérlet történt a számító- 
gépen futó szolgáltatások feltérképezésére, mégpedig oly 
módon, hogy az összes portot végig próbálta az illető, 
hogy kiderítse, melyek vannak nyitva. 

Ha ilyen riasztást kapunk, először is azonosítanunk kell a port 
scan forrását. Hasonlítsuk ezt össze a célszámítógépen futó 
szolgáltatásokkal. Ellenőrizzük az access logokat, találunk-e 
bennük jogosulatlan hozzáférésre utaló jeleket. Ha találunk 
ilyeneket, ellenőrizzük a kiszolgálót, hogy minden rendben 
van-e (Ha nem találunk akkor is! Biztos, ami biztos.) Ha a cso- 
magszűrés be van kapcsolva, és az ajánlásoknak megfelelően 
van beállítva, csak a valamilyen célból megnyitott portok (pél- 
dául közzétett kiszolgálók) fognak válaszolni a port scan-re. 


IP half scan attack 

Ez a riasztás azt jelenti, hogy ismételt kísérletek történtek 
a TCP csatorna kiépítésére (vagyis a TCP handshake, vagy 
ha úgy tetszik ,,chip-chip-choka" lebonyolítására) egy távo- 
ti számítógéppel, de a távoli gép valamiért , elfelejtette" 
elküldeni a csatorna kiépítését befejező ACK csomagokat. 
Jó, jó. Biztosan feledékeny! De miért baj ez? Egy szabvá- 
nyos transmission control protocol (TCP) kapcsolat felépí- 
tése egy SYN csomag célszámítógép felé küldésével kezdő- 
dik. Ha a megcélzott vár kapcsolatot az adott porton, ak- 
kor egy SYN/ACK csomaggal válaszol. A kapcsolatot kezde- 
ményező fél egy ACK csomaggal válaszol, és már fel is 
épült a kapcsolat. Ha a megcélzott gép nem vár kapcsola- 
tot az adott porton, egy RST csomaggal fog válaszolni. 

A legtöbb rendszer nem naplózza a lezárt kapcsolatokat, 
egészen addig, amíg az utolsó ACK csomag is meg nem ér- 
kezett a forrástól. Egy RST csomag utolsó ACK helyetti kül- 
désével a kapcsolat sose épül fel, és éppen ezért a kapcso- 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
2001. 10. 


26 





27 


BIZTONSÁG TSA SERVER (IV. " RÉSZ) 
lat nem is lesz naplózva. Mivel a kapcsolatot kezdeménye- 
ző könnyedén megállapíthatja, hogy a célgép SYN/ACK vagy 
RST csomagot küldött, azt is könnyedén megállapíthatja, 
hogy pontosan mely portok vannak nyitva, és mivel nem 
küldi el az utolsó ACK csomagot, az áldozat nem is fogja 
észrevenni a kísérletezést. Kivéve persze ha ISA Server-e 
van, és be van kapcsolva az Intrusion Detection! 

Ha ilyen eseményt tapasztalunk, véssük jól az agyunkba, 
meg persze egy tiltó csomagszűrő szabályba a mókás kísér- 
letező IP címét. 


Land attack 

Ez a riasztás arról tájékoztat, hogy olyan TCP SYN csomagot 
kaptunk, amelynek meghamisították a forrás IP címét és port 
számát, hogy megegyezzen a megcélzott IP címmel és port 
számmal. Ha a támadás sikerrel jár, egyes TCP megvalósítá- 
soknál hurkot eredményez, melynek eredményeként a számí- 
tógép bemutatja a kék halálnak megfelelő cselekvéssorozatot. 


Ping of death attack 

Valaki nagy mennyiségű adatot helyez el egy Internet Control 
Message Protocol (ICMP) echo reguest (ping) csomagban. Ha 
a támadás sikeres, egy kernel buffer túlcsordul, amikor a szá- 
mítógép megpróbál válaszolni. Az eredmény ugye egyértelmű. 
Ha ilyet tapasztalunk, tiltsuk az Internet felől érkező ICMP echo 
reguest csomagokat. Alapértelmezésben ezek tiltva is vannak. 


UDP bomb attack 

Ez a riasztás azt jelenti, hogy valaki megkísérelt egy érvény- 
telen User Datagram Protocol (UDP) csomagot küldeni. Ez né- 
mely régebbi operációs rendszernél , kék halált" okoz, amikor 
megkapja a csomagot. Az okot igen nehéz megállapítani. 

A további támadások a küldő IP cím blokkolásával megelőz- 
hetők. 


Windows out-of-band attack 

A riasztás arról értesít, hogy egy out-of-band DoS támadást 
kíséreltek meg egy számítógép ellen, amit az ISA Server 
véd. A sikeres támadás eredménye: DoS. 

A további támadások itt is a küldő IP címének blokkolásá- 
val védhetők ki. 

Ha egy lehetséges behatolási kísérletet észlelt, az ISA riasz- 
tása elindíthat egy adott cselekvéssorozatot, amely az ese- 
mény naplózásától akár az ISA Server kikapcsolásáig terjed- 
het. A leginkább javasolt eljárás olyan riasztás küldése, ami a 
lehető leghamarabb magára vonja a rendszergazda figyelmét. 
A behatolásészlelés riasztása által az application logba írt 
események jól jönnek a behatolási kísérletek elemzésekor, 
és az azokra történő válaszadáskor. Az alábbi ábrán egy Win- 
dows out-of-band attack által generált eseménynapló-be- 
jegyzés látható. Mint látható, a forrás IP cím naplózva van. 
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Date 1719/2001 Source: — Microsott ISA Server 4 
Time 15-05 Category None 

Type Warning — EventID: 15101 t 
User: NZA Bz 
Computer: SCH3O SEZZZEN 
Description 





ISA Server detected a windowt ott-of-band attack írom Internet Protocol 
IP) address 138.140.59.20. For more information abou this even, see 
IISA Server Hep.. 


Data GC BytesC Ward: 








5 Behatolás nyoma az eseménynaplóban! 


Fontos tudnunk, hogy a behatolásészlelő technológiák 
egyáltalán nem ,bolondbiztosak", és ez alól az ISA sem ki- 
vétel. őszintén szólva az ISA Server elég szerény kísérletet 
tesz a behatolásészlelés megvalósítására, tehát ne ringas- 
suk hamis biztonságérzetbe magunkat. A próbálkozás azért 
mindenesetre dicséretes. 


Összegzés 

Összegezve a fent leírtakat, a következő fontos ajánlásokat 

érdemes mindig betartani, a csomagszűrés, és a hozzá kap- 

csolódó behatolás-észlelés beállításakor: 

B Kapcsoljuk be a csomagszűrést. 

Kapcsoljuk be az IP fragment-ek szűrését. 

Kapcsoljuk be az IP options szűrését. 

Kapcsoljuk ki a H.323 bővítést, ha nincs rá szükségünk. 

Kapcsoljuk be a behatolásészlelést, főleg akkor, ha nincs 

erre külön rendszerünk. 

Ha bekapcsoltuk a behatolásészlelést, gondosan állít- 

suk be az adott behatolási kísérletekhez tartozó riasz- 
tást (és az általa végrehajtott cselekvéssorozatot) . 

"8 Minden lehetséges eszközzel teszteljük rendszerünk. 

ütésállóságát". Persze csak tesztrendszerben. Éles rend- 

szerben csak olyannal kísérletezzünk, ami biztosan nem 

okoz kárt. Az eredményt használjuk fel a lehető legszigo- 

rúbb szabályrendszer kialakításához. 


dFddd 


HP 


BP 
MCSE 
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ASP Suli (IX.rész) 


CDO for 


Windows 2000 


Az ASP Suli előző részében megismertük a kissé már poros 
CDONTS objektummodellt, most a friss, ropogós változat, a 
CDO for Windows 2000 következik. Az elmúlt havi cikkhez ha- 
sonlóan, a CDO for W2K sem szigorúan ASP objektummodeltL, 
bárki használhatja, aki a programozás során hozzáfér COM 
objektumokhoz (scriptből, vagy akár programokból is). Mint 
mindig, az aktuális példakódok letölthetők az [1] címről. 


A CDO for Windows 2000 objektummodellje 
Az alábbi ábrán a CDO for W2K objektummoddellje látható (a 
teljes dokumentáció a weben a [2] címen található) . 
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5 A CDO for Windows 2000 objektummodellje 








Első pillantásra talán rémisztőnek látszik, de valójában nem az. 
Egy nagyon okosan megkomponált, könnyen érthető objektum- 
modellel állunk szemben, aminek bizonyos elemei ráadásul nem 
is tartoznak a CDO for Windows 2000 részei közé: a levelek, le- 
vélrészek egyes részeit képező (akár bináris) adatfolyamok ke- 
zelését, azok betöltését-mentését az ADO (Active Data Objects) 
Stream objektum végzi. Az ADODB.Stream objektumot az ASP Su- 
liban már többször használtuk, de akit komolyabban érdekel a té- 
ma, lapozza fel a weben az objektum referenciáját ([3]). Az ob- 
jektum használata a példaprogramokban önmagáért beszél majd 
(persze angolul :-) ). A másik, ADO-ból kölcsönvett objektum az 
ADODB. Field, amely tulajdonképpen nem más, mint egy névvel 
azonosítható tárolóobjektum. Ilyen Field objektumokat tartalmaz- 
nak a CDO for W2K objektummodelljének számos pontján meg- 
található Fields kollekciók. A Stream-hez hasonlóan a Field ob- 
jektum használata sem okozhat majd gondot, de a biztonság ked- 
véért bárki fellapozhatja a weben a hivatalos referenciát ([4]). 


Levélküldés hirtelen felindulásból 

Ha nem is egy sorból mint a CDONTS-ben, de gyakorlatilag 
egyetlen objektum létrehozásával is kitöltögetésével a CDO 
for W2K is képes levél küldésére (cdo1.asp): 
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Set oMsg - Server.CreateoObject("CDO.Message") 
oMsg.From - 
b """Fu Beno"" cbenogfalatrax.hu2" 
oMsg.To - 
4 """Gipsz Jakab"" cCgipszjéfalatrax.hu:" 
oMsg.Subject -— "CDO demo 1." 
oMsg.TextBody - "Hello CDO for Windows 2000!" 


oMsg.Send 


Azaz: létrehozzuk az új üzenetet jelképező CDO.Message ob- 
jektumot; kitöltjük a feladó és a címzett mezőket; megad- 
juk a levél témáját, a szöveges törzs tartalmát, végül meg- 
hívjuk a Send() metódust. Ami feltűnhet, az a címzés mód- 
ja: szándékosan nem az egyszerű e-mail címeket adjuk meg, 
hanem az SMTP szabványnak megfelelően a delikvensek tel- 
jes nevét is ("név" ce-mail címz formában). A másik dolog, 
ami feltűnhet, maga a cím: nem reklám, de utóbb kiderült, 
hogy az előző számban használt példaprogramok a Teszt 
Magazin nem létező felhasználóinak küldtek csini próbale- 
veleket ((2teszt.hu; az érintettektől ezúton kérünk elnézést 
:-)) ). A Efalatrax.hu domain garantáltan nem létezik :-). 


A Configuration objektum 

A Configuration objektum a levelek elküldésének, kezelésé- 

nek módját meghatározó beállításokat tartalmazza. Az álta- 

lános alapértelmezés az alábbi: 

"8 Ha van a gépen SMTP szolgáltatás, a CDO for W2K a kime- 

nő leveleket az SMTP szolgáltatás PickUp könyvtárába 

másolja; a bejövő leveleket a szolgáltatás Drop könyv- 

tárából veszi (figyeljük meg, hogy ezesetben a CDO ma- 

ga semmiféle hálózati kommunikációt nem végez). 

Ha nincs, megpróbálja a gépen található Outlook Express 

beállításait használni. 

Minden létrehozott üzenetobjektum (CDO.Message) ezeket a be- 

állításokat örökli, de ha akarjuk, a Configuration objektum segít- 

ségével ezt a viselkedést akár üzenetenként megváltoztathatjuk. 

A CDO.Configuration objektum kétféle képpen jöhet létre: 

8 Új, üres objektumként létrehozzuk, hogy majd később egy 
Message objektumhoz rendeljük: 


Set oCnf 5 


3 Server.CreateObject("CDO.Configuration") 


"8 Egylétező Message objektum alapértelmezett Configuration 
mezőjét lekérdezve megkapjuk az üzenetre érvényes 
beállításokat tartalmazó példányt: 


Set oMsg - Server.CreateObject("CDO.Message") 


Set oCnf - oMsg.Configuration 
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A Configuration.Load() metódus segítségével az objektum- 
ba be (vagy újra-) tölthetjük az alapértelmezett beállításo- 
kat (a metódus paramétere az, hogy honnan): 
oCnf.Load(-1) " az alapértelmezések betöltése 
oCnf.Load(1) " az SMTP Service beállításai 
oCnf.Load(2) " az Outlook Express beállításai 
A Configuration objektum ezen kívül egyetlen dolgot tartal- 
maz, ez pedig egy Fields kollekció, amely a beállításokat 
tartalmazza (emlékszünk, sok-sok ADODB. Field objektumot). 
A conf1.asp kódja az alábbi: 


Set oMsg - Server.CreateObject("CDO.Message") 


Set oCnf 5 oMsg.Configuration 


For Each oField In oCnf.Fields 
Response.Write "cb5" § oField.Name § "€/bo: " 
HW § oField.Value § "cbr2" 


Next 


A példakódból szépen látszik a Field objektumok használatának 
módja (tulajdonképpen két fontos dolgot kell megjegyeznünk ró- 
luk: a mező nevét a .Name; értékét pedig a . Value jellemző tárol- 
Ja). A For Each ciklus segítségével kilistázzuk a Configuration ob- 
jektumban található összes mezőt és azok értékeit. Az eredmény: 





-hemas.microsoft.com/edo/configurationípostusing 0 
-hemas.microsoft.com/cdo/configuratior/sendusing 1 
-hemas.microsoft.comedo/configurationsmtpserverpickupdirectory wtnetpublmadroot Pickup 
./schemas.microsoft.com/edo/configurationfusemessageresponsetext True 
temaszcalendar:timezoneid: 2 





5 A CDO alapbeállításai 


Ne ijedjünk meg a mezők nevétől (a sorok vastag betűs ré- 

sze), ez csak a manapság divatos névteresítés eredménye (a 

CDO for W2K összes mezőjét ilyen nevekkel érhetjük el, hacsak 

nincsenek kivezetve, mint valamelyik objektum jellemzője). A 

Configuration mezők neve és azok jelentése egyébként a 

CDO referenciából kileshető ([5]). Ezek szerint például: 

"8 A válaszüzenetek generálásakor a magyar nyelvet hasz- 
náljuk (languagecode - hu). 

"8 Az SMTP leveleket a helyi SMTP kiszolgáló Pickup könyv- 
tárába másolva ,küldjük el" (sendusing - 1). 

"8 Az SMTP kiszolgáló Pickup könyvtára (smtpserverpickupdi- 
rectory). 

"1 Válasz írásakor és levelek továbbításakor automatikusan 
generáljuk a válaszüzenet tartalmát (usemessagerespon- 
setext - True). 

Állítsuk be, hogy a CDO ne (fájlműveletekkel) a helyi, hanem 

egy , távoli" SMTP kiszolgálót használjon (cdo2.asp). (Ez persze 

lehet a saját gépünk is, csak most hálózaton keresztül, ,,kívülről" 
érjük el az SMTP kiszolgálót.) Ehhez az üzenetobjektum létreho- 
zása után az alábbi néhány sor beszúrására van szükség: 


Set oCnf - oMsg.Configuration 
oCnf.Fields("http://schemas .microsoft . com/cdo/ 

4. configuration/sendusing") - 2 "sendUsingPort 
oCnf.Fields("http://schemas .microsoft . com/cdo/ 


b configuration/smtpserver") - 
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oCnf.Fields.Update 


A többszörös sortörésre a hosszú mezőnevek miatt volt szük- 

ség (ahol a típuskönyvtár rendelkezésre áll, ott használhatjuk a 

mezők rövid neveit, lásd pl.: [6]). De lássuk csak, mit tettünk: 

8 Az oCnf objektumba betöltöttük az üzenetobjektum kon- 

"8 A ,sendusing" mezőnek 2 értéket adtunk, ez azt jelenti, 
hogy hálózaton keresztül küldjük a levelet. 

"8 Az ,smtpserver" mezőben megadtuk a használni kívánt 
SMTP kiszolgáló címét (ez lehetne egyébként NetBIOS 
név vagy IP cím is). 

2 Végül a legfontosabb: ha azt akarjuk, hogy a mezőkön vég- 
zett változtatások érvényre jussanak, a módosítások után 
meg kell hívnunk a Fields kollekció Update() metódusát! 
(Ez a szabály a CDO összes mezőkollekciójára érvényes). 

Ha megtehetjük, próbáljuk ki mi történik, ha a cdo1.asp-t és a 

cdo2.asp-t akkor futtatjuk, amikor a célbavett SMTP kiszolgáló 

éppen nem érhető el! A Pickup könyvtárat használó cdo1.asp 
simán lefut (a levél bekerül a Pickup könyvtárba, és az SMTP 

Server újraindításakor el fog menni) , míg a cdo2.asp hibát jelez: 





Technical Information (for support personnel) 


e Error Type: 
CDO Message .1 (0x80040213) 
The transport failed to connect to the server, 
Zasp9/cdoz2.asp, line 16 








0 Ha nem a helyi SMTP kiszolgáló Pickup könyvtárát 
használjuk, fel kell készülnünk a hálózati problémákra 


Ezért írtam az előző számban, hogy a legtöbb esetben ké- 
nyelmesebb, ha a postázás kínját-baját az SMTP kiszolgáló- 
ra bízzuk. De van ennél cifrább is, például ha a levelező ki- 
szolgáló tiltja a relay-zést (rajta keresztül nem, vagy csak 
bejelentkezés után enged idegen tartományba levelet külde- 
ni), a következő sokatmondó hibát kapjuk: 





Technical Inforrnation (for support personnel) 


6 Error Type: 
(0x8004020F) 
Z7asp9/7mickZ.asp, line 19 








5 Ha a hálózati problémákat megoldottuk... 


A CDO az ilyen problémák elkerülése érdekében képes beje- 
lentkezni a távoli SMTP szolgáltatásba. Ezt megint kétféle- 
képpen tehetjük meg: 

- Ha a távoli SMTP kiszolgáló Windows, a CDO for W2K képes 
biztonságos NTLM authentikációval bejelentkezni. Ilyenkor 
csak egyetlen mezőt kell beállítani, a bejelentkezéshez az 
aktuális felhasználó adatait használja fel a rendszer. 


oCnf.Fields("http://schemas .microsoft . com/cdo/ 

4 configuration/smtpauthenticate") - 2 " cdoNTLM 

-8 Ha ez nem menne (vagy az SMTP kiszolgáló nem Win- 
dows), marad a nyíltjelszavas azonosítás. Ilyenkor meg 
kell adnunk a felhasználónevet és jelszót is (ne felejt- 
sük el az Update() meghívását!) : 
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oCnf.Fields("http://schemas .microsoft.com/cdo/ 
4 configuration/smtpauthenticate") — 1 " cdoBasic 
oCnf.Fields("http://schemas .microsoft . com/cdo/ 

$  configuration/sendusername") - "usernév" 
oCnf.Fields("http://schemas .microsoft . com/cdo/ 


8 configuration/sendpassword") - "jelszó" 


Ennek két buktatója van: egyrészt, ilyenkor a felhasználó- 
név és jelszó a hálózaton titkosítatlanul utazik; másrészt 
az .asp kód önmaga tartalmazza a felhasználónevet és jel- 
szót, ami - bár normális esetben a felhasználó az ASP ol- 
dal kódját nem láthatja - egyáltalán nem jó gyakorlat. 

Az első problémára megoldást jelenthet az, ha a levelező ki- 
szolgáló támogatja az SSL csatornán keresztüli kommunikációt, 
bekapcsolhatjuk azt, és akkor a teljes levélküldés - az esetle- 
ges bejelentkezéssel együtt is - titkosított csatornán halad: 


oCnf.Fields("http://schemas .microsoft . com/cdo/ 


8, configuration/smtpusessl") - True 


Egy érdekes jellemzőre szeretném felhívni a figyelmet: 
előfordulhat, hogy hiába adjuk meg, hogy nyílt jelsza- 
vas felhasználóazonosítást szeretnénk; a CDO for W2K 
lekérdezi a kiszolgálót, és ha az támogatja a jóval biz- 
tonságosabb NTLM azonosítást, azt fogja használni! 


Az üzenetobjektum (CDO.Message) 
A konfigurációs lehetőségek után most lássuk a - korábban 
már egy példa erejéig használt - CDO.Message objektumot, 
ami egy üzenetet , testesít" meg. Mint tudjuk, az SMTP levél 
(ha az MIME), belülről egy fastruktúra, ami a levél tartalmá- 
tól függően lehet akár egyetlen (fa)levél (tipikus SMTP levél, 
tiszta szöveges tartalommal) , de lehet üzenetrészek bonyolult 
hierarchiája is. A már sokszor emlegetett MIME Browser képes 
nekünk grafikus formába önteni a MIME levelek tartalmát: 
mullipart/signed  (charset ; encoding 7bit; size: 783927 1002) 
Ta multipart/mixed  (charset : encoding: 7bit; síze: 72466 — 9422) 
A— Ég muttipait/related (charzet: : encodíng: 7bit; size: 46460 — 597) 
B-— -Ég mutipatt/atematíve. (charset : encoding: Zbll; size: 10737 129 
ÉJ ted/olain . ([charzet: is0-8859-2; encodíng" guotedpiintable: size: 144 7 02) 
€]) text/himi (charset is0-8859-2: encoding: gyoted-printable; size 645 7 12) 
image/ípeg  [charset : encoding: base64: size: 45121 " 582) 


ÚT] appicalion/msword  (charset: ; encoding: base64; size 26774 " 347) 
EA oppkcationzepkcs7-signature. (charset: ; encoding: base64; size: 4105" 52) 








5 Egy MIME levél néha bonyolult stuktúrába szervezett 
üzenetrészekből áll 


Azt már sejtheti az Olvasó, hogy az üzenet nem lesz más, 
mint üzenetrész (BodyPart) objektumok többszintű kollek- 
ciója (lásd később), de mintha a pár oldallal ezelőtt a 
Message objektum gyors bemutatásakor nem lett volna szó 
üzenetrészekről. Címzés, téma, tartalom, és kész. 

A magyarázat: a belső felépítéstől függetlenül minden le- 
vélnek valahol van szöveges , törzse" (a fenti ábrán például 
a legalsó szinten látható text/plain üzenetrész tartalmaz- 
Za). A levelekhez csatolhatunk fájlokat (a fenti ábrán pél- 
dául az application/msword üzenetrész ilyen) is. A Message 
objektum ezért - miközben részletekbe menően felboncol- 
hatjuk - tartalmaz ,kivezetett" részeket, csak hogy meg- 
könnyítse a programozó dolgát. Az élveboncolás előtt lás- 
suk tehát a fontosabb ,shortcut" mezőket (IMessage inter- 
fész, lásd még: [7]): 
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8 .From - a levél feladója. 

"5 .To - a levél címzettje(i). Ha egynél több címet adunk 
meg, azokat vesszővel kell elválasztani. 

B .Cc, .Bcc — másolat, vakmásolat. A címzettek megadását 

lásd fennt. 

.Subject -— a levél témája. 

.TextBody -— az üzenet szöveges törzse. 

.MIMEFormatted - True értéke jelzi, hogy az üzenet MIME 

formátumú. 

.HTMLBody - az üzenet HTML törzse (szöveg). 

.AutoGenerateTextBody - True (alapértelmezett) értéke 

esetén, ha HTML levelet írunk (.HTMLBody), a CDO au- 

tomatikusan legenerálja hozzá a megfelelő tiszta szö- 
veges változatot (.TextBody). 

8 .MDNReguested - True értéke jelzi, hogy a levélről kérünk 
olvasási, kézbesítési visszajelzést, lásd még: 

-8 .DSNOptions - értéke attól függ, hogy milyen típusú 
visszajelzést szeretnénk kapni. Az egyes számértékek 
összeadhatók, jelentésük pedig: 0,1 - nincs visszajelzés; 
2 - visszajelzés kézbesíthetetlenség esetén; 4 — vissza- 
jelzés sikeres kézbesítés esetén; 8 - visszajelzés, ha a 
kézbesítés átmenetileg nem lehetséges (késleltetett). 

"8 .SentOn, .ReceivedTime -— Ez a két dátummező csak akkor 
él, ha nem küldendő, hanem kapott leveleket dolgo- 
zunk fel. Értékük ilyenkor a levél küldésének illetve 
megérkezésének dátuma. 

A Message objektum Fields kollekciója az üzenet fejlécé- 

ben található mezők, beállítások tartalmát, valamint né- 

hány röptében generált adatot tartalmaz. Az msgfields.asp 

betölti a html1.eml fájlba mentett levelet, és kilistázza a 

Fields kollekció tartalmát. Ha nézegetjük, észrevehetjük, 

hogy a mezők nagyjából leképezik az üzenet fejrészében 

található fejléceket. Ami feltűnhet: 

b Az ,urn:schemas:httpmail:htmldescription" mező a levél 
törzsének HTML; a ,urn:schemas:httpmail:textdescrip- 
tion" pedig a tiszta szöveges változatát tartalmazza 
(ez a Message objektum .HTMLBody illetve a .TextBody 
jellemzőinek értéke). 

5) A ,urn:schemas:mailheader:x-sajatfejlec:" mező és annak 
értéke. Az X-SajatFejlec fejlécet mi csempésztük az el- 
mentett .eml fájl fejrészébe, a CDO pedig szépen betöl- 
ti azt. Ez visszafelé is igaz: ha egy üzenetobjektumban 
létrehozunk egy ,urn:schemas:mailheader:x-akármi" ne- 
vű mezőt, az üzenet fejrészében megjelenik, mint fejléc. 

A Message objektum .EnveloperFields kollekciója csak az Event 

Sink-ek programozásánál használható, nekünk egyelőre nincs 

szükségünk rá. Ami még érdekes lehet, az az üzenetrész-objek- 

tumokat, illetve azok kollekcióit visszaadó jellemzők, úgyis- 
mint: 

"5 .BodyPart -— az üzenet fő üzenetrésze (a MIME fa törzse) ; 
maga az üzenet 

"8 .TextBodyPart — az üzenet szöveges törzsét tartalmazó 
üzenetrész-objektum ; 

-8 .HTMLBodyPart - az üzenet HTML törzsét tartalmazó 
üzenetrész-objektum 

Új üzenetrészeket a Message objektumon keresztül (mert- 

hogy máshogy is lehet, lásd később) a következő két metó- 

dus segítségével adhatunk az üzenethez: 

8 AddaAttachment(): egy csatolt fájlt ad az üzenethez 

"8 AddRelatedBodyPart(): egy üzenetkomponenst ad az 
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üzenethez (amit az üzeneten belül felhasználhatunk, de 
mint csatolt fájl, nem látható). 

Lássunk egy-egy példát mindkét esetre, először egy csatolt 


fájl képében (attach.asp): 


oMsg.HTMLBody z "cboGirl: attachedc/b2" 
oMsg.AddaAttachment Server.MapPath("msgirl.jpg") 


Az AddAttachment() metódusnak egyébként nem csak a 
csatolandó fájl nevét, hanem URL-jét is megadhatjuk (ld. 
attach2.asp) , ilyenkor a CDO letölti azt és csatolja a levél- 
hez. (Az esetleg szükséges felhasználónevet és jelszót a má- 
sodik és harmadik paraméterként adjuk át). 

Lássuk most, hogy néz ki az, ha a képet nem a HTML levél- 
hez csatolva, hanem abba beillesztve szeretnénk elküldeni 
(related.asp) : 


oMsg.HTMLBody - "img src-""cid:pic.jpg""2" 
oMsg.AddRelatedBodyPart 
4 Server.MapPath("msgirl.jpg"), "pic.jpg", 0 


Kezdjük hátulról: az .AddRelatedBodyPart metódus három 

(öt) paramétert vár: 

"8 A csatolandó fájl neve vagy URL-je 

"8 Aza név (ID), ahogy a csatolt elemre az üzenetben majd 
hivatkozunk 

"0 A hivatkozás típusa: lehet ID alapján (0), vagy relatív 
URL-lel (1) 

"I Az utolsó két paraméter ismét a fájl letöltéséhez esetleg 
szükséges felhasználónév és jelszó 


Az üzenet kimentése fájlba / betöltése fájlból 

A cikk elején szó esett már arról, hogy a CDO az adatmozgatás- 
hoz az ADODB.Stream objektumát használja fel. Az üzenet 
kiírását és beolvasását azonban nem a Message, hanem a 
DataSource interfészen keresztül kérdezzük le (egyébként ez az 
interfész is ugyanarra az objektumra mutat, mint a Message). A 
DataSource interfész tartalmazza a Stream-be (és másba) men- 
téshez, illetve onnan való betöltéshez szükséges metódusokat. 
Az üzenet elmentése például az alábbi sorokból áll: 


Set oStream - Server.CreateObject("ADODB.Stream") 
ostream.Open 
osStream.Type - 1 " adTrypeText 
oStream.Charset -— "us-ascii" 
Set oDS - oMsg.DataSource 
oDS.SaveToObject oStream, " Stream" 
ostream.SaveToFile "file.eml", 2 


"adSaveCreateOverwrite 


Azaz, sorrendben: létrehozunk egy Stream objektumot; 
megnyitjuk azt, majd beállítjuk, hogy szöveges adatokat 
szeretnénk tárolni, azt is ASCII kódolásban (hiszen az SMTP 
levél nem is tartalmazhat mást). Ezután a CDO Message ob- 
jektum .DataSource jellemzőjének segítségével lekérdezzük 
az üzenet DataSource objektumát. A DataSource objektum 
.SaveToObject() metódusának első paramétere a célterület 
(esetünkben a Stream objektum) , második paramétere pedig 
a célobjektum típusazonosítója (ez Stream esetén ,, Stream"). 
Ezután már csak a Stream objektum SaveToFile() metódusát 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
2001. 10. 


CDO FOR WINDOWS 2000 


kell meghívni, és máris kész az elmentett üzenet. Az üze- 
net betöltése ennek inverze, valahogy így (az msgfields.asp 
példaprogramban megtalálható) : 


Set oStream - Server.CreateObject("ADODB.Stream") 
oStream.Open 

oStream.LoadFromFile Server.MapPath("htmll.eml") 
Set oMsg - Server.CreateObject("CDO.Message") 

Set oDS - oMsg.DataSource 

oDS.OpenObject oStream, " Stream" 

Fájlok feltöltése a webkiszolgálóra 

Szép-szép, mondhatná a kedves olvasó, de hogyan kerülnek 
fájlok a kiszolgálóra? Ez központi kérdés a webprogramozás 
során, és nem csak a levelezés kapcsán: előbb-utóbb minden 
projektben feladat lesz a feltöltött fájlok fogadása. Ha meg- 
nézzük az évek óta érvényes HTML4 szabványt (mellesleg ezt 
illik is nézegetni: [8]), feltűnhet egy különleges HTML elem: 


LINPUT type-r"file" name-"filename"5 


File" típusú cINPUT: mező! Ha pedig megjelenítjük, egé- 
szen érdekesen jelenik meg a böngészőben: 









ZZáhttp localhost/asi MSat 





5 A , file" típusú cINPUT2 mezővel már kereshetünk fáj- 
lokat a lemezünkön 


Hurrá, hiszen ezzel lehet böngészni! Nosza, próbáljuk ki 
(fileup1.asp)! Válasszunk ki egy fájlt, majd küldjük el és 
nézzük, mi érkezik a kiszolgálóhoz... Ha jó fájlt néztünk, 
Hát, ez még nem tökéletes. Azt is olvashatjuk, hogy ennek 
az elemnek a használatakor a cFORM: HTML elem enctype 
paraméterét át kell állítani, valahogy így: 


CFORM method-"post" action-"fileup2.asp" 


enctype-"multipart/ form-data"5 


Próbáljuk ki ezt (fileup2.asp) , hátha nagyobb szerencsével járunk! 
Jobb lett? Dehogyis... most még a fájl neve sem jött át... vagy 
mégis? Lessük meg valahogy a hálózati forgalmat, ami a böngésző 
és a kiszolgáló között zajlik, és valami ilyesmit látunk majd: 


Content-Type: multipart/form-data; 
8 boundaryzs-------— 7412443018907e2 


7412443018907e2 





Content-Disposition: form-data; name-"filename"; 
4 filename-"C:lteszt.txt" 


Content-Type: text/plain 


Ez egy teszt uzenet. 
Ezt a fajlt probaljuk meg feltolteni a kiszolgalora. 
Vajon sikerrel jarunk? 

—--—-- 7412443018907e2— 
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Ismerős? Ugye feltűnt, hogy a böngésző a kérdőív postá- 
zásakor egy korrekt MIME üzenetet hozott létre, Content- 
Type fejléccel, határolókarakterekkel, az egyes részek sa- 
ját fejlécével (Content-Disposition) , adattípusával? És per- 
sze, megkaptuk a fájl teljes tartalmát - pontosabban nem 
mi, hanem a webkiszolgáló. 

Most már csak keresni kellene valamit, ami képes ebből a 
MIME forgatagból intelligensen kikeresni a feltöltött ada- 
tokat (plusz a kérdőív további mezőinek adatait, ha esetleg 
voltak, hiszen azok is ebbe az üzenetbe kerülnének) . 

A Microsoft ehhez kiadott egy ingyenes komponenst 
(cpshost.dll), de azt körülményes használni. Ehelyett - és ez 
itt lehetne akár a reklám helye - bemutatunk egy ugyancsak 
ingyenes, viszont ügyes és könnyen használható komponenst: 


Az aspSmartUpload komponens 

9] címről ingyenesen letölthe- 25 sin 
Tölkámgnetie segítségével köny- R pud 
nyen feldolgozhatjuk a feltöltött adatokat. A komponens 
telepítése egyszerű: töltsük le a tömörített állományt, és a 
benne található két .dll-t másoljuk olyan helyre, ami ben- 
ne van a path-ben! Ezután már csak egy dolgunk van, be- 
regisztrálni a komponenst. Menjünk az aspsmartupload.dll-t 
tartalmazó könyvtárba és adjuk ki az alábbi parancsot: 


regsvr32 aspsmartupload.dll 


Az ASPSmartUpload használata egyszerű (a weben árztásé [Rá 
[10]). Először hozzuk létre az objektumot, majd töltsük bé 
le a kérdőívből kapott adatokat (form.asp és aspsmart.asp): 


Set O0AS - Server.CreateObject 
4 ("aspSmartUpload.SmartUpload") 
0AS.UpLoad 


Ezután már a kezünkben van az irányítás. Lássuk például, mi- 

lyen fontosabb jellemzői vannak a SmartUpload objektumnak: 

"0 .TotalBytes - az összes feltöltött adat mérete (fájlok és 
a form többi eleme együttesen) 

8 .TotalMaxFileSize — a feltölthető fájlok maximális mére- 
te összesen 

- .MaxFileSize - a feltölthető fájlok maximális mérete 
egyenként 

"0 .AllowedFilesList — az elfogadott fájlok kiterjesztéseinek 
listája (pl. ,,txt,doc,xls") 

"8 .DeniedFilesList — a fel nem dolgozandó fájlok kiterjesz- 
téseinek 
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Az utolsó négy korlátozó jellegű beállítás, még az 

.UpLoad() metódus meghívása előtt állítsuk be. A fonto- 

sabb metódusok a következők: 

2 .UpLoad(): betölti a form adatait az objektumba 

"8 .Save(): elmenti az összes feltöltött fájlt a megadott 
könyvtárba 

Az objektum kollekciói pedig: 

"8 .Files — a feltöltött fájlok listája (File objektumok) 

8 .Form - a kérdőív mezőinek listája (Item objektumok) 


A File és az Item objektumok 

Az aspsmart.asp példaprogramban bemutatjuk az objektu- 

mok használatának módját, most csak néhány fontos jel- 

lemzőjükre térünk ki. Először lássuk a File-t: 

"8 .Name - az cINPUT: elem neve 

"8 .FileName - a fájl megadott neve (pl. attach.txt) 

"5 .ContentType - a fájl MIME tartalomtípusa 

"b .IsMissing - értéke True, ha az INPUT: objektum nem 
tartalmaz feltöltött fájlt (mindig ellenőrizzük!) 

Az Item objektumról csak annyit érdemes megjegyezni, 

hogy a .Values jellemzője egy vagy több értéket tartalmaz- 

hat. Feldolgozás előtt kérdezzük le a számukat (erre is lát- 

hatunk példát az aspsmart.asp fájlban). 

A fájlokkal viszont dolgunk van: ha már feltöltötték, fel 

kellene őket dolgozni. Például elmenthetjük fájlként (a 

File objektum .SaveAs(, fájlnév") metódusával) egy átme- 

neti könyvtárba, és ez nekünk pontosan kapóra is jön! Ké- 

szítsük hát el és próbáljuk ki a csatolt fájlt is kezelni ké- 

pes levélküldő komponensünket (newmail.asp)! 

A (jó-jó, kezdetleges) példaprogrammal kapcsolatban két 

dolgot kell megjegyezni: 

2 Az aspSmartUpload objektum .UpLoad() metódusa hibát 

ad vissza, ha üres kérést (nem POST-ot) akarunk vele 

feldolgoztatni. Ezért mielőtt meghívnánk, ellenőrizzük 

a HTTP kérés típusát a Reguest.ServerVariables 

(. REDUEST METHOD") segítségével 

A példában a Windows Temp könyvtárába mentjük átme- 

netileg a feltöltött fájlokat, majd megpróbáljuk azokat 

törölni (általában az IUSR felhasználónak a törléshez 

nincs joga) . Éles rendszerben alakítsunk ki egy megfe- 

lelő könyvtárat csak erre a célra, megfelelő jogosultsá- 

gokkal, de a webről közvetlenül el nem érhető helyen. 


Fülöp Miklós 
mick 2netacademia.net 
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[3] http://msdn.microsoft.com/library/en-us/ado270/htm/mdobjstream.asp 

[4] http://msdn.microsoft.com/library/en-us/ado270/htm/mdobjfield.asp 

[51] http://msdn.microsoft.com/library/en-us/cdosys/html/ cdosys schema configuration.asp 

[6] http://msdn.microsoft.com/library/en-us/cdosys/html/ cdosys cdoconfiguration module.asp 

[71 http://msdn.microsoft.com/library/en-us/cdosys/html/ cdosys interfaces.asp 


[8] http://www.w3.org/TR/html4/ 
[9] http://www.aspsmart.com/ 


[10] http://www.aspsmart.com/liblocal/docs/en/aspsmartupload/help/Objects.htm 
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Bevezetés 

Előző számunkban áttekintettünk néhány tervezési fondor- 
latot gyors SOL Server adatbázisok kialakításának reményé- 
ben. Ott utalást tettem arra, hogy a fáradságos munkával, 
trigger segítségével kialakított denormalizálást az SOL 
Server is képes megvalósítani, számunkra minimális munká- 
val. A titok nyitja az indexelhető nézetekben keresendő. Er- 
ről, valamint az indexek működéséről, belső felépítéséről és 
alkalmazásukról fogok ebben a részben értekezni. 


Miért kell az SOL Servernek index? 

Nem kell. Az SOL Server jól elvan indexek nélkül is, és végre- 
hajt bármilyen parancsot anélkül, hogy egy árva indexet kap- 
na. Indexek használatával viszont jelentősen felgyorsíthatók 
az adatbázisműveletek, és sokszor a forrásadatok mennyiségé- 
től független sebességű adatbázisparancsokat hajthatunk vég- 
re. Hogy legyen összehasonlítási alapunk, először nézzük meg 
hogyan tárolja az SOL Server a táblák adatait indexek nélkül. 


Adatbázisok - alulnézetben 

Leegyszerűsítve nézzük meg az SOL Server adattárolási struk- 
túráját. Az SOL Server a 7-es verzióval kezdve közönséges 
operációs rendszer fájlokban tárolja az adatbázisok adatait. 
A fájlokon belül az alapvető tárolási egység a lap (page). Egy 
lap 8 kByte méretű, és ez a legkisebb mozgatható egység az 
adatbázisfájlok és a memória között. A táblák sorai lapokon 
tárolódnak, a sorok nem ívelhetnek át lapok között, azaz el 
kell nekik férniük egy lapon. Emiatt a maximális sorhossz 
8196 Byte mínusz némi adminisztráció, a végeredmény az, 
hogy 8060 Byte marad a táblák sorainak tárolására. 

A lapokat az SOL Server nyolcas csoportokba fogja, és ezt a 
formációt extent-nek hívja. Amikor a szerver lefoglal lapo- 
kat egy tábla vagy index részére, akkor ezt mindig extent- 
enként teszi meg - az extent a minimális helyfoglalási egy- 
ség. Azaz, ha létrehozunk egy táblát, az rögtön kap egy 
64k-s extent-et. Ez elég furcsán nézne ki ha lenne 1000 
táblánk, mindegyikben csak annyi sort tárolnánk, amennyi 
elférne egy lapon, ennek ellenére a szerver 1000x64k-t 
(64MByte) lefoglalna, mert minden táblát külön extentre 
pakolna. Hogy ez ne így legyen, egy extentnek több lakója 
is lehet, maximum nyolc objektum (tábla vagy index) élhet 
benne. Ők a mixed extent-lakók. 

Amint egy tábla adatai már nem férnek bele egy extent-be, az 
SOL Server allokál egy újabb extentet neki, amit azután kizá- 
rólag ez a tábla birtokolhat. Ezt nevezik uniform extentnek. 
Minden adatbázisfájl elején van egy bevezető lap, amit File 
Header-nek hívnak. Ez az adatbázisfájllal kapcsolatos álta- 
lános adminisztrációs információkat tartalmaz. 
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A helyfoglalás nyilvántartásához az SOL Server saját admi- 
nisztrációs lapokat helyez el az általunk tárolni kívánt hasz- 
nos lapok előtt és között. Minden fájl elején (a 2. és a 3. 
pozíción) van két lap, egy Global Allocation Map (GAM) és 
egy Shared Global Allocation Map (SGAM). Mindkettő egy 
bittérkép az extentek foglaltságáról (egyetlen biten ábrázol- 
ja egy extent, azaz 64k foglaltságát!) , és egyszerűen azt ír- 
ják le, hogy egy extent szabad-e, részben foglalt (mixed 
extent és van rajta szabad lap), vagy teljesen foglalt (uni- 
form extent vagy teli mixed extent). Mindkettő egy lapnyi, 
azaz 8192 Byte-nyi információt tud tárolni, azaz kb. 64000 
extent-ről képesek nyilvántartást vezetni. Ez 64000 x 64k 
(extenteket, nem lapokat tart nyilván) - 4GByte. Azaz, ha 
egy adatbázisfájl mérete 4 GByte fölé megy (nem ritka) , ak- 
kor betelik az első GAM és SGAM. 

Mit tesz ilyenkor a szerver? Az adatbázisállomány végén le- 
foglal magának egy újabb adminisztrációs célokra fenntar- 
tott extentet, feltölt egy újabb GAM-ot és SGAM-ot, és ezen 
kezdi el jegyezni az újabb 4 Giga extentjeit. Így élnek, míg 
meg nem halnak... 

A Page Free Space (PFS) nevű lap (lásd előző ábra), azt tárol- 
ja, hogy az általa leírt lapok mennyire telítettek. Minden egyes 
byte egy lapot ír le, így egy PFS 8000 lapot képes nyilvántar- 
tani. Emiatt ő meg 8000 laponként ismétlődik a fájlokban. 
Miért ez a sok redundáns információ az adatblokkok foglalt- 
ságáról? Hisz a PFS teljes egészében elég lenne, a GAM és 
SGAM nem mond többet nála. Azért, mert a GAM-SGAM pá- 
ros pont a durva felbontása miatt rettenetesen nagy tarto- 
mányokról ad képet az adatbáziskezelőnek, így két GAM-nyi, 
azaz 16 kByte-nyi információ felolvasásával azonnal meg le- 
het mondani 4 GByte-nyi részről, hogy abban hol vannak 
szabad helyek. Egy intenzíven dagadó adatbázisban gyakran 
kell allokálni újabb és újabb extenteket, és ilyenkor minimá- 
tis órajelciklus alatt megtalálja a szabad helyeket az SOL 
Server. Azután jöhet a PFS azt eldöntendő, hogy a kikeresett 
extent melyik lapja szabad, vagy van rajta annyi hely, ameny- 
nyi elég mondjuk a beszúrandó adatnak. Lehet azt monda- 
ni, hogy sokkal gyakoribb a módosítás egy adatbázisban, 
mint a beszúrások száma. Jó, de mi van akkor, amikor a mó- 
dosítás után egy sor hosszabb lesz, mint előtte volt, és nem 
fér már el az eredeti lapján? Ilyenkor a szerver helyet keres 
(GAM, SGAM, PFS) és a módosított sort már ott helyezi el, 
persze az eredeti helyét felszabadítva. 

Az extentek és a lapok katonás rendben vannak nyilvántart- 
va. Honnan tudja a szerver, hogy mondjuk a 145345-edik 
lap melyik táblához vagy indexhez tartozó információt tá- 
rol? A GAM-ok és a PFS-ek erről egy szót sem szólnak. Ami- 
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kor létrehozunk egy táblát vagy egy indexet, akkor az SOL 
Server létrehoz egy uniform extentet, aminek első lapját le- 
foglalja a tábla vagy index által használt extentek nyilván- 
tartására. Ezt a lapot hívjuk Index Allocation Map-nek 
(IAM). A neve azért megtévesztő, mert nem csak az inde- 
xek, de a táblák lapjait is ezek tartják nyilván. 





Mivel egy IAM csak korlátozott számú extentet tud leírni, 
az IAM-ok össze vannak láncolva. Minden index-hez vagy 
táblához létezik egy IAM lánc. 


Ez itt egy nagy halom... 

Heap. Ez a kulcsszó azokhoz a táblákhoz, amelyekhez nem 
hozunk létre indexet. Indexek nélkül az IAM az egyetlen 
logikai kapocs, amely egy tábla adatlapjait összeköti. Ez 
azt jelenti, hogy ha egy lekérdezést hajtunk végre egy in- 
dex nélküli, azaz heap (halom) struktúrában tárolt táblán, 
akkor az SOL Servernek fel kell olvasni az IAM(ok) által 
leírt összes adatlapot, és azokban turkálva kell kikeresnie 
a kért információt. Ha például 10 millió sornyi információt 
tárolunk egy táblában, egy sor átlagos hossza 200 byte, 
akkor az SOL Server-nek 2 GByte-nyi adattömeget kell 
felolvasni a merevlemezről, és végigkeresgélni a memóriá- 
ban. Tű a szénakazalban (halomban). Ez még akkor is na- 
gyon időigényes, ha az egész tábla a Buffer Cache-ben 
(RAM-ban) van. A keresési módszer neve table scan, és 
nagy táblák esetén üldözzük tűzzel-vassal. Meg indexszel. 


Főzőcske indexekkel 

Szeretnék enni egy kis Juhtúróval töltött gombakalapot. Mit 
tesz ilyenkor a jólnevelt informatikus? Nem, nem kezd el az 
interneten keresgélni. Az olyan mesterséges dolog. Előveszi 
Hargitai György Vegetáriánus ételek című könyvét. Felüti a 
könyvet a közepén. Mit lát ott? Mozarellás sült brokkoli. En- 
nél egy picit visszább lesz a Juhtúrós gomba. Megfelezi a 
maradék oldalakat, felüti a könyvet, és a szemébe ötlik a 
Francia sárgarépa. Tóltótuk Béláim - mondaná Kállay Ferenc 
a Tanúban. Túlságosan előrementünk. Még néhány előre- 
hátra lapozás, és megtalálja a hőn áhított ételt. Mit csinált 
az éhes informatikus? Clustered index seeket! 

A clustered index seek azt jelenti, hogy az elérni kívánt infor- 
mációk már előre be vannak rendezve aszerint a feltétel sze- 
rint, ami szerint keresünk benne. Én az étel neve alapján ke- 
restem, és a könyv lapjai pont így vannak berendezve, ezért 
nagyon gyorsan megtaláltam benne a keresett információt. 
Megkívántam egy Pikáns csirkét. Az előző könyvben végrehaj- 
tott sikeres clustered index-es keresés után előveszem Péter 
Sándorné és Nagy Jánosné bestsellerét, az Esély szakácsköny- 
vet. Némi lapozás után csalódottam állapítom meg, hogy 
nincs benne clustered index, nem az ételek nevei alapján van 
berendezve. Lehetőségeim: elkezdem lapozni a könyvet, és 
valahol majd csak kiszúrom a pipit, azaz a table (könyv) scant 
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végzek. Nem biztos, hogy kivárnám ezt a csirkét. 

A másik lehetőség, hogy fellapozom a könyv végén talál- 
ható tárgymutatót, ahol az ételek már betűrendben van- 
nak. Az előbbi felezős módszeremmel kikeresem a csirkét. 
Ezt nagyon gyorsan meg tudom tenni, különösen, hogy a 
tárgymutató csak néhány lap hosszú. A Pikáns csirke a 260- 
adik oldalon lakik. Mit kezdek ezzel az információval? Meg- 
jegyzem ezt a kulcsot, és belekezdek egy újabb felezgetős 
keresésbe immáron a tényleges adatlapokon, kihasználva azt 
a tényt, hogy a könyv lapjai a lapok sorszámai alapján van- 
nak bekötve. Viszonylag gyors kereséssel megvan a csirke. 
Ez már nem volt olyan egyszerű fogás, mint az előbbi, de 
egy tétel esetén megéri vele vergődni. Ha viszont azzal 
bíznának meg, hogy gyűjtsem ki az összes olyan ételt, ami 
k betűvel kezdődik (kb. 150 darab), akkor inkább azt vá- 
lasztom, hogy végiglapozom a teljes ötszáz oldalas köny- 
vet, semmint, hogy állandóan előre-hátra lapozzak a 
tárgymutató kénye kedve szerint. 

Mit hajtottam végre a pipi keresése közben? Nonclustered in- 
dex seeket! Az adatok nem a keresési feltétel szerint voltak fi- 
zikailag berendezve, de kaptunk egy struktúrát (tárgymutató — 
index) , amiben csak a keresendő adatok voltak felsorolva (in- 
dexkulcs) , és egy-egy a tényleges adatokra mutató pointer. 
Egyedi, néhány sornyi adatok esetén nem nagy munka és idő 
ezen indirekció mentén felszedni a sorokat, de ha sok adatra va- 
gyunk kíváncsiak (a lekérdezés eredményhalmaza sok sort tartal- 
maz), akkor sokszor kisebb munka végigmenni a teljes táblán, 
és kikeresni a kért információkat az index használata helyett. 
Itt a magyarázat arra, amire sokan panaszkodnak: ,Raktam 
egy indexet a táblára (nem tud róla, de nonclustered-et) , 
ám ennek ellenére az SOL Server nem használja azt, table 
scan-t csinál!" Hogyne, mert okos, és tudja, hogy tovább 
tartana az index mentén felszedni a sorokat, mint direkt- 
ben kikeresni őket. De honnan tudja, hogy egy lekérdezés 
eredménye hány sort fog eredményezni, hisz a szűrési fel- 
tételben lehet akár igen összetett feltétel is? 

Nos, van neki egy tanácsadója, akit úgy hívnak: statiszti- 
ka. Az SOL Server eloszlási információkat gyűjt a tábláink- 
ban tárolt adatokról, és kis hisztogrammok formájában tá- 
rolja is őket. A lekérdezések végrehajtása előtt kielemzi a 
statisztikákat, és azok alapján meg tudja becsülni, hogy 
nagyjából a forrástáblák hány százalékát fogja érinteni a 
művelet. Csak nagyjából, mert ezek mintavételezett sta- 
tisztikai információk, nem egzakt arányok. Miután tudja 
mekkora részét kell a táblának elérni, és tudja, hogy mi- 
lyen indexek állnak ehhez a rendelkezésére, ki tudja vá- 
lasztani, hogy melyik adatelérési stratégia lesz a legkisebb 
költségű, és azt fogja választani. 

Ezek a döntések igen összetettek is tudnak lenni. Például 
több tábla JOIN-olása esetén egyáltalán nem mindegy, 
hogy milyen sorrendben hajtja végre az összekapcsolást. 
Lehet, hogy az egyik sorrend esetén csak pár száz sornyi 
információt kell átgyúrnia, míg más sorrendet választva 
több milliót. 4 tábla esetén 4! (faktoriális), azaz 24 kom- 
binációt kell kielemeznie. 10 tábla esetén 10! - 3628800- 
at. Mire ezt mind végigelemezné, lemenne a nap, és még 
nem csinált semmit, csak azon gondolkodott, hogy hogyan 
fogjon neki a munkának. Ezt a hozzáállást ismerjük embe- 
reknél, de az SOL Server nem ilyen. Nagyszámú lehetséges 
végrehajtási terv esetén heurisztikákat vet be, olyan dön- 
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téseket hoz, amelyek nem hoznak biztosan jó eredményt, 
de az esetek többségében igen. Így rengeteg végrehajtási 
tervet még az elején kidob a pályázók közül, így a végére 
már csak néhányat kell tényleg kielemeznie. 

Mondja azt valaki, hogy az informatika egzakt tudomány! 
Nem egzakt, de nem is azt várjuk tőle. Azt várjuk tőle, hogy 
általában jól szolgáljon ki minket. Ha nem azt teszi, akkor 
még mindig jöhetünk a nagy eszünkkel, és ráerőltethetjük az 
általunk kieszelt végrehajtási tervet a szerverre — optimizer 
hintek használatával. Erről azonban nem írok bővebben, mert 
sok ember elbízza magát, és okosabb akar lenne az SOL Szer- 
vernél. Sok siralmasan teljesítő alkalmazás van emiatt a vi- 
lágban. Majd mi megmutatjuk a szervernek! Láttam már pár 
ilyet. Ilyenkor elhívnak szakérteni, ledobálom a hinteket, és 
csodák csodája, az alkalmazás gyorsabb, mint valaha. 


Az Indexek lelkivilága 

Nagy vonalakban nézzük meg hogyan tárolja az SOL Server az 
indexeket. Ígérem nem lesz sokkal nehezebb a főzőcskénél. 
A szerver mindkét típusú indexet (clustered és nonclustered) 
B-fában tárolja. A B betű nem a binárisra, hanem a 
Balanced-ra (kiegyenlített) utal. A fa csomópontjaiból kiin- 
dulva több csomópontot is elérhetünk. Ha bináris lenne, ak- 
kor mindig csak kettéágazna. A fát úgy építi a szerver, hogy 
nagyjából mindig szimmetrikus legyen, azaz ne legyen felko- 
paszodás az egyik helyen, és lelógó ágak a másikon. Máskép- 
pen fogalmazva úgy, hogy az indexlapok nagyjából ugyanan- 
nyi sort tartalmazzanak. Erre utal a kiegyenlített jelző. 
Minden egyes index egy-egy ilyen fát jelent. Az indexek 
ugyanolyan 8k-s lapokon élnek, mint az adatok, és minden 
indexnek van saját IAM-ja, ami az indexet alkotó extent- 
eket fogja össze. Emellett az index lényegét az adja, hogy 
a fastruktúrában tárolt indexbejegyzések az indexelendő 
oszlop szerint vannak berendezve, így a fát természetes 
sorrendben bejárva az indexet alkotó kulcsok szerint ren- 
dezve kapjuk vissza a kulcsokat. 

Legyen például egy emberek adatait tároló táblánk, amiben 
a családnévre hozunk létre egy indexet. Az SOL Server egy 
olyan fát épít, amelyet a gyökérszintről kiindulva a család- 
nevek alapján rendezve járhatjuk be. Például keressük Feke- 
te Lajost. A gyökérből elindulva a szerver látja, hogy az áb- 
rán másodikként ábrázolt közbenső lapon találja meg az F 
és G betűvel kezdődő családnevű sorokat. Az abban találha- 
tó bejegyzésekből kiderül, hogy levélszinten a bal szélső 
lap tárolja az FA és a FO közötti kezdőbetűjű embereket, te- 
hát ha van közöttük Fekete, akkor az csak azon a lapon le- 
het. Ezután a lapon található néhány sorból már könnyedén 
(bináris kereséssel) megtalálja a keresett sorokat, ha létez- 
nek. Látható, hogy egy sor megtalálásához nem kellett fel- 
túrni az összes adatlapot, hanem néhány indexbejegyzés 
kiolvasása után elegánsan megvolt a keresett lap. 

Ezt az indexstruktúrát, amikor a levélszinten egyből az ada- 
tokat találjuk meg clustered index-nek nevezzük. Miután 
tudjuk, hogyan működik, teljesen természetes, hogy egy 
táblán csak egy clustered index hozható létre, mert az in- 
dex létrehozása egyben be is rendezi az adatlapokat az in- 
dex által megkívánt sorrendbe. Márpedig fizikailag csak 
egyféleképpen lehet sorbarendezni az adatsorokat. 
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5 Clustered index 


Mivel levélszinten rögtön ott vannak a keresett adatok, a 
clustered index akkor is nagyon hatékonyan tud működni, 
ha a lekérdezés a tábla jelentős részét érinti. Mint a fenti 
ábrán látható az adatlapok is és a közbenső szint(ek) lap- 
jai is össze vannak fűzve egy kétirányú láncolt listában. 
Emiatt tartományok keresése anélkül is tud működni, hogy 
állandóan végig kellene menni a fa közbenső levelein min- 
den egyes sor eléréséhez. Például Furfangos és Haragos kö- 
zötti neveket lekérdezve az SOL Server meghatározza a 
legelső lapot, ahol a legkisebb kezdőbetűjű értékes infor- 
máció nyugszik (levélszint 2. lap), és a lista mentén addig 
halad előre az adatlapok olvasásában, amíg el nem éri a le- 
kérdezésben definiált utolsó elemet. 
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0 Nonclustered index 


A nonclustered index fája gyökér és közbenső szinten azo- 
nos a clustered indexével. A különbség levélszinten szem- 
beötlő: míg clustered indexnél ott rögtön az adatokat talál- 
juk meg, nonclustered index esetén ott csak egy mutató 
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van a tényleges adatsorra. Ez alapban egy adatbázisfájl 
azonosítóból, egy lapazonosítóból és egy sorazonosítóból 
áll. 100 sornyi információ felolvasásához 100-szor be kell 
járni a fát, és 100-szor kell hozzáférni az adatlapokhoz. Le- 
het, hogy fizikailag az összes sor egy adatlapon van, de 
akkor ahhoz az egy laphoz kell az SOL Server-nek 100-szor 
hozzáférni. Így érthető, hogy nagymennyiségű adatot (ti- 
pikusan a tábla több mint 1099-át) érintő lekérdezéseknél 
az SOL Server nem fogja használni a nonclustered index- 
et, inkább végigmegy közvetlenül az adatlapokon. A lán- 
colt lista itt is fel van építve, így az elejét megfogva most 
is közvetlenül végig tud gyalogolni az adatokon. 

Heap esetén, azaz, ha nincs semmilyen index egy táblán, 
a szerver az IAM lapokat elemezve tudja csak összevadász- 
ni az adatlapokat. Ebben az esetben egyedül az IAM teremt 
kapcsolatot a lapok között. Ez általában a legkevésbé ha- 
tékony módszer, ezért a táblákat mindig célszerű minimum 
egy clustered indexszel berendezni. 

A clustered index nagy kincs, nem érdemes az elsődleges kulcs- 
ra elpazarolni. Elsődleges kulccsal úgyis pontszerű lekérdezése- 
ket szoktunk végrehajtani, arra tökéletes egy nonclustered in- 
dex is. Az viszont kell! Nehogy úgy tegye le valaki a cikket, 
hogy azt olvasta, hogy nem kell index az elsődleges kulcsra.! 
Hol érdemes bevetni a clustered index-et? Olyan oszlopra, 
ami szerint gyakran végzünk szűrést, és a lekérdezés ered- 
ményes sok sort ad vissza. Olyan oszlopokra, amelyeknél 
előnyös lehet az adatok eleve rendezett tárolása. Például a 
GROUP BY és az ORDER BY szereti a clustered index-et. 
Emellett a gyakran keresett oszlopok, például az idegen 
kulcsok oszlopai is hálásak bármilyen indexért. 


Indexelhető nézetek 

Miután mindent tudunk az indexekről, itt az ideje, hogy 
rátérjünk az előző részben beharangozott csodára, az inde- 
xelhető nézetre. Ha visszaemlékszünk, ott egy egyszerű 
összegzést gyorsítottunk fel egy olyan segédtábla alkalma- 
zásával, amiben mi tartottuk karban az előre összegzett 
eredményeket triggerek segítségével. Láttunk, hogy műkö- 
dött, de nem volt egyszerű. Van azonban egy nagy segít- 
ségünk, az indexelhető nézet. 

A hagyományos nézetek (View) nem mások, mint megne- 
vezett SOL lekérdezések. Azaz becsomagolunk egy SOL le- 
kérdezést egy nézetbe, és a többi lekérdezésben úgy hivat- 
kozunk a nézetre, mintha ő egy fizikai tábla lenne. Pedig 
a valóságban mindig lefut a törzsében kijelölt lekérdezés. 
Az SOL 2000-ben nemcsak táblára, de nézetre is hozhatunk 
létre indexet. Ez azt eredményezi, hogy a nézetben kijelölt 
adatokat tényleg előre kiszámítja az SOL Server, és fizikailag 
egy táblában eltárolja. Ez számunkra láthatatlan, mi csak 
annyit észlelünk, hogy a felindexelt nézeten keresztül a lekér- 
dezések nagyon gyorsak, és a szerver nem nyúl hozzá az alap- 
táblához. Az alaptábla (táblák) változásait át kell vezetni a né- 
zet mögötti táblába és indexstruktúrába is. Ezt csináltuk trig- 
gerrel az előző részben. Örömteli, hogy az SOL Server ezt 
megoldja helyettünk teljesen automatikusan. Csak létrehozzuk 
az indexet a nézeten, és a szerver átvezet minden változást. 
A felgyorsítandó lekérdezés így nézett ki: 
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SELECT 

OrderID, 

SUM(Ouantity : UnitPrice t (1-Discount)) 
FROM [Order Details]) 
GROUP BY OrderID 


A célunk a részösszegek előre kiszámítása. Hozzunk létre 
egy nézetet, ami a fenti lekérdezés kimenetét generálja, 
csak vegyük bele a sorok számát csoportonként. Ez szüksé- 
ges feltétel az index létrehozásához a nézeten: 


CREATE VIEW FastOrdersView 
WITH SCHEMABINDING AS 
SELECT 
OrderID, 
SUM(Ouantity " UnitPrice t (1-Discount)) as 
szumma, 
COUNT BIG(t) AS sorokszama 
FROM dbo.[Order Details] 
GROUP BY OrderID 


A nézeten csak akkor tudunk indexet létrehozni, ha több 
feltétel is teljesül rá. Ezeket az [1] címen található példa- 
kódban foglaltam össze, terjedelmi okokból nem részlete- 
zem őket. A fenti nézetben a WITH SCHEMABINDING is a 
feltételek része, ez megakadályozza, hogy a nézet mögötti 
táblák szerkezetét módosítsuk, így kirántsuk a talajt alóla. 
A nézet kész, már csak létre kell hozni rajta az indexet. Né- 
zeten az első index kötelezően unigue (csak egyedi értéke- 
ket tartalmazó) clustered index kell legyen. Ráadásul 
GROUP BY esetén a GROUP BY utáni oszlopra kell ráadni, 
úgyhogy sok választásunk nem maradt: OrderID oszlop. 


CREATE UNIOUE CLUSTERED INDEX IDXCLU OrderID 
ON FastOordersView (OrderID) 


Az index létrehozásakor elkészül a nézet kimenetét tároló lát- 
hatatlan háttértábla és maga az indexfa, azaz a nézet mate- 
rializálódik. A meglepetés akkor ér bennünket, amikor ismét 
végrehajtunk az eredeti, felgyorsítandó lekérdezést az alap- 
táblán, azaz az Order Details-en: az SOL Server nem fogja ki- 
számolni a szummát, hanem egyszerűen előveszi a már előre 
kiszámolt eredményeket a nézetből! Azaz létrehoztunk egy in- 
dexelt nézetet, és ettől felgyorsult egy olyan lekérdezés, ami- 
ben nem is hivatkoztunk a nézetre. Ez már tudomány! 


Soczó Zsolt 
Zsolt.Soczo(2netacademia.net 


A cikkben szereplő URL-ek: 


[1]: A cikkben szereplő script-ek — 
http://technet.netacademia.net/download/sgl 
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Szappanoperánk előző részében koncepcionálisan áttekintettük 
a SOAP (Simple Object Access Protocol) alapjait. Akinek elég egy 
átfogó kép, az olvassa el még egyszer azt a részt, és ezt most 
hagyja ki. Akit érdekel az is, hogy a SOAP elmélet hogyan néz 
ki a gyakorlatban is, annak ajánlom ezt a fejezetet is. 
Áttekintjük, hogy mely konkrét technológiák képesek test- 
közelbe hozni az absztrakt SOAP szabványt, és hogyan le- 
het ténylegesen megírni egy SOAP alapú alkalmazás ügyfél- 
és kiszolgálóoldali komponenseit is. 


Már megint a metaadatok! 

Van egy felturbósított HTTP kiszolgálónk, amely boldogan 
várja, hogy SOAP kéréseket szolgáljon ki. A felturbósítás 
részleteivel, azaz, hogy egy szimpla webszerverből hogyan 
lesz SOAP szerver a cikk második felében foglalkozunk. 

A SOAP segítségével nagyszerű üzeneteket csereberélő alkal- 
mazásokat lehet írni, azonban a mai programozók objek- 
tumokban gondolkodnak, és nem akarnak egyedi SOAP 
borítékokat cipelni - arra való a postás. Nem akarnak 
foglalkozni a paraméterek és a visszatérési értékek bájt- 
folyammá kódolásával és dekódolásával. (Nehéz a 
Serialization/ Deserialization fogalmak magyarítása, de 
értelmében a bájtfolyammá kódolás írja körül leginkább a 
serialization fogalmát.) Ki lesz az a postás? 

Amikor egy COM komponens valamely metódusát meg akar- 
tuk hívni, akkor honnan tudtuk, hogy annak mely inter- 
fészei mely metódusokat támogattak? A Type Library volt 
az, ami specifikálta a COM komponensek interfészeit és az 
azokban megvalósított metódusok típusát, szignatúráját. A 
szignatúra valami olyasmi, mint amikor egy C nyelvű prog- 
ram header (.h) állományában leírjuk, hogy egy függvény 
milyen típusú paramétereket vár, azok közül melyik milyen 
irányú információt hordoz, mi a hívási konvenció és milyen 
a visszatérési érték típusa. Azaz egy metódus szignatúrája 
a metódus neve, a paraméterek száma és típusa, valamint a 
visszatérési érték típusa. Ahhoz, hogy egy műveletet vagy 
metódust használni tudjunk, szükségünk van annak szig- 
natúrájára. Hasonlóan néz ez ki a SOAP világban is. 

Egy SOAP kiszolgáló hogyan tudja publikálni a rajta meghívható 
metódusok szignatúráját? Erre találták ki a WSDL-t (Web Services 
Description Language), magyarul Webszolgáltatások Leíró- 
nyelve. A WSDL egy XML alapú leírónyelv, amely - a COM Type 
Library-hez hasonlóan - a SOAP kiszolgáló által publikált metó- 
dusok szignatúráját dokumentálja. 

Egy picit itt álljunk meg. Eddig SOAP szerverről beszéltem 
általában, most pedig előjöttem a WSDL fogalmával, aminek 
már a nevében sem a SOAP, hanem Web Service szó áll. Miért? 
A SOAP egy közös fejlesztés eredménye a Microsoft, IBM, Ariba, 
Developmentor (Don Box cége, ismerős a neve?) és még jópár 
cég részvételével. Az előző részben láthattuk, hogy a SOAP 
specifikáció nyitva hagyja az implementációs részleteket. Mivel 
mi most egy konkrét ügyfél-kiszolgáló alkalmazást írunk, min- 
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denképpen ki kell kötnünk egy konkrét implementációnál. A 
világban sok SOAP megvalósítás létezik, ezek közül mi most a 
Microsoft Soap Toolkit lehetőségeivel fogunk foglalkozni. 
Habár a webszolgáltatások hátterében tetten érhetjük a 
Microsoft munkáját is, a technológia nem a Microsoft-é! A 
WSDL nyelv már a World Wide Web konzorciumnál jár szab- 
ványosításra, csak nyilván fiatal kora miatt még nem ajánlás 
státuszú. Egyébként is hamarosan világos lesz, hogy a 
hangzatos webszolgáltatás név mögött egy SOAP szerver lakik. 
Vissza a WSDL-re! Hogyan állítjuk elő egy konkrét SOAP 
szerver által publikált metódusok WSDL leírását? Például 
kézzel, notepad-ban. A WSDL az XML Schema szabványra 
épít, így aki tud sémát írni, az már majdnem tud WSDL-t is 
írni. Álljon itt egy WSDL részlet: 


Sdefinitions 
xmlns : sz"http: //www.w3.org/2001/XMLSchema" 
xmlnsz"http://schemas . xmlsoap.org/wsd1/" 5 


€s:element namez"Add"5 
£s :complexType2 
Cs :seguences 
Ss:element minOccurs-z"1" maxOccursz"1" 
namez-"A" typez"s:float" /5 
cs:element minOccursz"1" maxOccursz"1" 
namez"B" types"s:float" /5 
£/s:seguences 
£/s:complexType2 


£/s:element5 


£s:element namez"AddResponse"5 
£s:complexType? 
£s :seguence5s 
£s:element minOccursz"1" maxOccursz"1" 
name-"AddResult" types"s:float" /5 
£/s:seguences 
£/s:complexType? 


£/s:element5 
c/definitionsz 


Ez bizony egy XSD (XML Schema) darabka. Ez a részlet egy olyan 
metódust ír le, aminek C-r-- (C4) nyelvű szignatúrája így néz ki: 


float Add(float A, float B) 


Mivel a metódushívás SOAP-ra leképezve nem más, mint egy 
kérés és arra adott válasz, ezért az Add elem a kérést írja 
le, amiben a metódus paramétereit deklaráljuk (float A, flo- 
at B). A kérésben szereplő metódus nevét Result-tal kiegé- 
szítve kapjuk vissza válaszként, így a második elemdeklará- 
ció a visszatérési értéket írja le. 
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Egy igen fontos tényt kell megfigyelnünk a fenti leírásban: a 
paraméterek típusosak, például az A paraméter típusa float. 
Mindezt az XSD-nek köszönhetjük, amiben a legtöbb ismert és 
a szoftveriparban széleskörben használt adattípust definiáltak. 


Egyszerű SOAP kiszolgáló 

Első SOAP kiszolgálónkat a Microsoft SOAP Toolkit 2.0 SP2 
segítségével írjuk meg. A SOAP Toolkit szabadon letölthe- 
tő az [1] címről. A példákat külön kell letölteni, azok a 
[2] címen találhatók. Addig, amíg nincs végleges .NET- 
ünk, és élesben kell fejleszteni, addig a Soap Toolkit segít- 
ségével is teljes értékű SOAP szervert írhatunk. 

A Toolkit segítségével SOAP üzeneteket egyszerű módon le- 
képezhetünk COM objektumok hívására. Mivel COM objektu- 
mot VB6-ban könnyű írni, már csak kellene egy alkalmazás, 
ami elkapja a SOAP kéréseket, és azok hatására meghívja a 
COM komponensünk megfelelő metódusát. Honnan tudja 
egy közvetítő alkalmazás, hogy mely SOAP hívást melyik 
komponens melyik metódushívására fordítsa át? Erre szol- 
gál a Web Services Meta Language (WSML) leíróállomány. 
Ez nem szabványos leírófájl, ne is keressék a World Wide 
Web konzorcium honlapján! Ez kifejezetten a SOAP Toolkit 
által nyújtott inplementációhoz kell. Még visszatérünk rá. 
A SOAP Toolkit kétféle kiszolgálóoldali ún. SOAP Listenert tar- 
talmaz: Internet Server API (ISAPI) listener és Active Server 
Pages (ASP) listener. Mindkét típus feladata a webszerverhez 
érkező SOAP kérések fogadása, feldolgozása, a kért komponens 
metódusának meghívása és a visszatérési értékek SOAP cso- 
magban történő visszaküldése. Mi magunk is írhatnánk ilyen 
programot, de minek bajlódjunk az összes SOAP fejléc és tar- 
talom elemezgetésével, amikor ezt megteszik helyettünk? 
Lássuk, mi van ebben a közvetítő alkalmazásban! 


1 SOAP Server 1 i 
(WsDLIWSMLI ! 












WSDLReader 
Kéréselemzés load()) 






WSDL Operation objektum 
e etek 






Mimg e! Call AddNum 
(Num. TB) 


IResutt] 


SOAP válasz 4———— őoapserializer[—.  —————— —SUM - 7 





A beérkező SOAP kérést a SoapReader komponens felolvassa 
és mint közönséges XML dokumentumot értelmezi. A vég- 
eredmény egy DomDocument objektum, ami a kérést repre- 
zentáló bináris XML fát tartalmazza. Közben a WSDLReader 
sem tétlenkedik, az felolvassa és értelmezi a SOAP szerverünk 
szolgáltatásait leíró WSDL, és a meghívandó COM objektum 
felé a kapcsolatot definiáló WSML fájlokat. Mivel azok is XML 
formátumúak, szintén egy-egy XML DOM-ba töltődnek be. 

A WSDLReader értelmezi a SOAP kérést, és készít egy 
WSDLOperation objektumot. Az meghívja a GetOperation- 
Parts() metódusát, ami a teljes WSDL/WSML fából kiszedi 
azokat a részeket, amelyek a konkrét kéréshez és válaszhoz 
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tartoznak. Emlékeztetőül a WSDL állomány az adott SOAP 
szerver összes metódusát írja le, de nyilván a paraméterek 
ellenőrzéséhez és a végrehajtáshoz csak a meghívandó me- 
tódushoz tartozó részt kell figyelembevennie. 

Ezek után a SoapServer minden egyes paraméterhez és a 
visszatérési értékhez készít egy SoapMapper objektumot, 
és feltölti őket a kérésben kapott paraméterekkel. A Soap- 
Server meghívja a kért feladatot ellátó metódust, amit a 
WSML fájlban kijelölt COM objektumban keres. A COM me- 
tódus visszatérési értéke ismét egy SoapMapper objektu- 
mon keresztül jön vissza. (Tudjuk, hogy egy metódushívás 
visszatérési értéke COM-ban mindig egy szám, HResult, de 
vannak kimeneti paraméterek, és például a VB is azzal szi- 
mulálja a visszatérési értéket). 

A megfelelő SoapMapper-ben rendelkezésre álló visszatérési ér- 
téket a SoapSerializer alakítja át a SOAP szabványnak megfele- 
lő formátummá. A SoapServer-nek már csak fel kell kapni ezt, 
és visszaküldeni az ügyfélprogramnak egy HTTP Response-ban. 
Amikor a SoapServer objektum vezényli le a teljes koncer- 
tet, akkor az ún. magasszintű API-t használjuk. Az esetek 
többségében ez megfelel nekünk, de akár alá is nyúlhatunk 
az imént vázolt folyamatnak, és a keretben látható objek- 
tumokkal mi is koordinálhatjuk a teljes folyamatot. Így pél- 
dául megoldhatjuk, hogy a háttérben nem COM objektumok 
ülnek, hanem Win32-es DLL-ek, vagy CORBA objektumok, 
vagy bármi, aminek a szolgáltatásait meg szeretnénk hívni. 
Térjünk vissza a listenerekre. Az ISAPI listenert akkor hasz- 
náljuk, ha ki akarjuk használni az ISAPI technológiában 
rejlő teljesítményt (ISAPI alkalmazásként lehet a leggyor- 
sabb webalkalmazást írni IIS - Internet Information Server 
alá), és ha közvetlenül nem akarjuk babrálni a SOAP üze- 
neteket. Ennek megfelelően az ASP megoldás lassabb lesz, 
de végrehajtás előtt kielemezhetjük a bejövő SOAP üzene- 
tet, így például saját biztonsági réteget vonhatunk a hívó 
és a SOAP kiszolgáló közé. Erre szükségünk lesz, ha nem 
tudjuk kihasználni az IIS integrált autentikációját, azaz ál- 
talában internetes környezetben. 

A SOAP kéréseket fogadó ISAPI alkalmazás neve soapi- 
sap.dil, és alapértelmezett módon telepítve a 


C:(Program FileslCommon FilesiMssoapt 


3 BinariesV 


mappában él. Alkalmazásához a wsdl állományokat tartal- 
mazó webszerver könyvtárakban a .wsdl kiterjesztéshez 
hozzá kell rendelni ezt az ISAPI dll-t. A Toolkit telepítés- 
kor ezt megteszi a gyökérwebre, de utólag a .NET Frame- 
work esetleg elhappolhatja a hozzárendelést. Ilyenkor jó 
tudni hol található a soapisap.dll. 

Ha ezen a kész ISAPI alkalmazáson keresztül akarunk egy 
SOAP hívást végrehajtani, akkor a SOAP ügyfélprogramnak a 
megfelelő .wsdl állományra kell hivatkozni. A kérést elkapja 
az ISAPI DLL, és a wsdl/wsml leírások alapján végrehajtja a 
megfelelő COM objektum kért metódusának hívását. 


Írjunk metaadatot! 

Létrehoztunk a IIS-en egy virtuális könyvtárat, ami mögé be 
van élesítve a soapisap.dil a .wsdl fájlokra irányuló kérések ke- 
zelésére. Már csak egy lépés van hátra a SOAP szerverünk mű- 
ködéséhez: meg kell írnunk a wsdl és a wsml állományokat. 
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Ha itt tartana a SOAP Toolkit, akkor most nem írtam volna meg 
ezt a cikket, mert ki az, aki metaadatokat akar kézzel írni? Ha 
már ott van az összes szükséges metaadat a SOAP-on keresztül 
publikálandó COM objektumunk Type Library-jében, akkor miért 
ne lehetne automatikusan generálni a wsdl/wsml fájlokat? 
Szerencsére kétféle wsdl/wsml generátort is kapunk, az 
egyik egy grafikus felületű manó (varázsló), a másik pedig 
egy parancssorból hívható .exe. Mindkettő egy dologra va- 
ló: COM Type Library alapján wsdl/wsml párost generál. A 
grafikus változat a Start Menü, Programs, Microsoft SOAP 
Toolkit, WSDL Generator menüpontból indítható, a parancs- 
sori változat, a wsdlstb.exe pedig a 

c:AProgram FilesMSSOAPMBinaries könyvtárban lakik. 

A publikálandó COM komponensünk egy egyszerű VB kompo- 
nens, amelynek PROGID-ja: SoapTestComp.FileMan, és az 
egyetlen metódusa: 


Public Function OlvasdEl(ByVal strFilePath As 
String) As String 


Ez felolvassa a paraméterként megadott szövegfájlt, és azt 
visszaadja a hívónak. Egy sima webszerver is ezt teszi, de 
példának jó lesz. A komponens forráskódja letölthető a [3] 
címről, számunkra bőven elég a meghívandó metódus szig- 
natúrája és a tőle elvárt működés. 

Jöjjön a varázsló! Elindítjuk a Soap Toolkit 2.0 Wizard-ot, 
ami némi bemutatkozás után megkérdezi, hogy milyen né- 
ven generálja le a wsdl/wsml fájlokat, valamint, hogy melyik 
.dll-ben (vagy másban) van a publikálandó COM komponens 
Type Library-je. Példánkban a fájlolvasó wsdl/wsml nevet 
adtam, és a Type Library a VB által fordított DLL-ben van, 
úgyhogy azt kell kiválasztani a listából. 

A következő lépésben a varázsló megmutatja a komponensünk ál- 
tal publikált metódusokat. Ha lenne több interfészünk, akkor 
mindegyiket kilistázná, és bármelyikből kiválogathatjuk a 
SOAP-ra ültetendő metódusokat (én is megtettem, mind az egyet) . 













E SOP Toolkit 2.0 Wizard 2] 
Select the services you would like to expose. 

You can select which services you would kke to expose ín yout WSDL file for your 

Web Service. 
KEZES TETTÉT] 
Only select the methods that 
ou would ie to expose. The 
wizard wil exckxde any methods / 
goudo not select. ] 
II you select a method that uses) 





A varázsló figyelmeztet egy igen fontos tényre. Ha olyan adat- 
típust használunk akár paraméterként, akár visszatérési érték- 
ként, amit az XML séma alapban nem ismer, akkor a generált 
wsdl/wsml dokumentumokban a kérdéses helyeken ????-ket 
fogunk látni, és nekünk kell kézzel megírni a típusdeklaráció- 
kat. Gondoljunk csak bele, milyen típusra képezné le a varázs- 
ló például valamely objektumunkat? Hisz semmi akadálya, 
hogy egy metódus egy objektumot adjon vissza, ugye? 
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Mit lehet ilyen helyzetekben tenni? Ilyenkor bizony át kell ír- 
ni a komponenst, és nekünk kell olyan típusokat használni, 
amelyek kompatibilisek a XSD-ben lefektetettekkel. Ha nincs 
meg az eredeti forráskód, akkor ez akár azt is jelentheti, 
hogy írni egy csomagoló komponenst, ami aggregálja a kiin- 
duló komponenst, és nekünk kell megírni az elvadult adattí- 
pusok (például saját objektumok) átalakítását XSD által is- 
mert típusokká, például string-gé. Objektumok esetén az ob- 
jektum teljes állapotát akarjuk serializálni string-gé, ezt át- 
küldjük egy SOAP üzenetben a hívónak, majd az visszaállítja 
belőle az eredeti objektumot. Ez persze azt jelenti, hogy ügy- 
féloldalra is kell írni egy olyan eljárást, ami képes a seriali- 
zált objektumból újra valódi objektumot gyártani (deseriali- 
2e). Ember legyen a talpán, aki ezt mind végigcsinálja! 

Én ismerek valakit/valamit, aki/ami ezt mind tudja, sőt képes 
arra, hogy transzparens módon, tetszőleges, általunk fabrikált 
objektumot serializál, átküld a dróton, majd visszaalakít, úgy, 
hogy ebből gyakorlatilag semmit sem lát a programozó. És 
nem kell hozzá alapjaiban megváltoztatni a publikálandó kom- 
ponenst. Meglepő, hogy már megint a .NET-ről beszélek ?! 
Akinek szüksége van saját típusok használatára még a .NET 
végleges megjelenése előtt, annak javaslom, hogy nézze 
meg a SOAP Toolkit-ben a Custom Type Mapper-ek kialakí- 
tásának részleteit. Ez egy kicsit más megközelítésben (XML 
DOM faragás) , de ugyanerre a problémára ad megoldást. 
De maradjunk a földön, a .NET-es megoldásról pedig majd a 
következő részben beszélünk. Tegyük fel, hogy jólfésült 
komponensünk nem használ semmilyen trükkös típust, amit 
nem ismer a wsdl generátor. A tömb szerencsére megy ne- 
ki, mert bár az nincs benne az XSD-ben, a SOAP-ba belerak- 
ták. Igazából a SOAP-ban csak két új adattípust kellett fel- 
venni a szerzőknek a XSD-ben találhatókon felül, a tömböt 
és a referenciát. Ezekkel majd későbbi számokban fogok 
foglalkozni, mert most nem maghasítót, csak egy egyszerű 
fájlolvasó szolgáltatást írunk. 

Komoly szellemi munkával kiválasztottuk a publikálandó 
metódust, Click Next. Meg kell adnunk, hogy hol lehet majd 
elérni a webszerveren keresztül a SOAP végpontunkat. Itt 
olyan URL-t kell megadunk, ahol a generált a wsdl/wsml . 
fájlokat lehet majd elérni HTTP-n keresztül. A varázsló nem 
hoz létre nekünk virtuális könyvtárat a webszerveren, a mi 
dolgunk, hogy az URL tényleg leíró fájlokra mutasson. 





(E SOAP Toolkit 2.0 Wizard 2 





SOAP fistener information 
Please specily your SOAP Estener location and listenet lype below. 


Please enter a valid URI folder where your listener will be located. 
r Listener URI 


URL [hitp//csharp.dotnet.hu/szappart 


(Example: hitp://servername/soaplisten/) 





C ASP 
6 ISAPI 





1XSD Schema Namespace (2001 prefered) 


km] 
About Cancel t Back Next? Einish 


Középen megadjuk a listener típusát, mi az egyszerűség ked- 
véért most ISAPI listener-t választunk. A legalsó listában ki- 
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választhatjuk, hogy melyik séma dialektusban generálódjon 
a wsdl típusleíró szekciója. Persze, hogy a legfrissebben. 
Az utolsó lépésben adjuk meg azt, hogy fizikailag hová ke- 
rüljenek a leíró fájlok. Az itt megadott mappát kell kipub- 
likálni az előző lépésben megadott URL mögé. Esetemben 
ez azt jelentette, hogy létrehoztam egy szappan nevű vir- 
tuális könyvtárat erre az elérési útra. 

Vigyázzunk, mert Windows 2000 alatt már legtöbbször nincs 
joga az Everyone-nak minden állományt olvasni, sőt, például 
a felhasználók ,My Documents"7-ében semmilyen joga sincs! 
Mint az alábbi képen is látható én a leírófájlokat a saját ,My 
Documents"-emen belül hoztam létre, és innen a webszerver 
nem tud Anonymous kéréseket kiszolgálni, mert nincs joga a 
könyvárhoz. Megoldás: a .wsdl állományokra adni kell olva- 
sási jogot az IUSR Gépnév felhasználónak, mert ennek a ne- 
vében éri el az IIS az állományokat. Emellett nyilván a kom- 
ponenst is el kell érnie, így arra is kell olvasási jog. 


(EZ SOAP Toolkit 2.0 Wizard 






Specify the location for the new WSDL and WSML files. 


The wizard will save the files in this folder. These files should be Web accessible in 
order to be exposed as Web Services. 


Select WSDL file character set 
G UTF-8 
C UTFA6 
Where would you like to store the new files? 


MingstsociDOTNETZODOtMy DocumentstáriciesüMLtamié Select 


5 A kaméleon SoapcClient, azaz ahol a való világ véget- 
ér, ott kezdődik a varázslat 


Láttuk, hogy kiszolgálóoldalon elvégzik helyettünk a piszkos 
munkát, és gyakorlatilag egy ötlépéses varázslóval elérhető- 
vé tettük a COM objektumunkat a SOAP-pal támadó ügyfél- 
programok felé. A másik oldal még egyszerűbb. Nézzük csak! 


Dim sc As New MSSOAPLib.SoapClient 
sc.mssoapinit 


"http: //localhost/szappan/fajlolvaso.wsdál" 


Ahelyett, hogy mi magunk állítanánk össze a SOAP kérést, 
létrehozunk egy példányt a SoapClient objektumból, és 
megadjuk neki a SOAP szervert leíró wsdl fájl elérését. Ő 
letölti ezt, értelmezi, és felkészül a SOAP hívás indítására. 
És itt jön a füst és tűz. A sc objektumunk átalakult! Ő már 
többé nem (csak) SoapClient objektum, hanem SoapTest- 
Comp.FileMan objektum is egyben! Ez azt jelenti, hogy 
meghívhatjuk az OlvasdEl metódusát, mintha az mindig is 
az ő része lett volna: 


Dim s As String 


s 5 sc.OlvasdEl("c:Wwinntisystem32lVeula.txt") 


És a hívás hipp-hopp kiköt az előbb gondos munkával elké- 
szített SOAP szerverünkön, ott meghívódik a VB komponen- 
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sünk azonos nevű metódusa, az eredmények visszatérnek, 
és mi pontosan ugyanazt a viselkedést kapjuk vissza, mint- 
ha a komponens a mi (ügyfél) gépen futna. Döbbenet. 

A SoapClient ebben az esetben un. Stub-ként (tuskó?) vi- 
selkedik, azaz úgy csinál, mintha ő lenne a távoli kompo- 
nens, de valójában csak úgy csinál, és a valódi munkához a 
távoli komponenst szólítja meg SOAP-on keresztül. Milyen 
jól elprogramozgatjuk a SOAP-ot, és még nem is láttunk egy 
darab SOAP borítékot sem. De ami késik, nem múlik! 


SOAP Trace utility 

Ő az utolsó lakója a SOAP Toolkit-nek. Segítségével belép- 
hetünk a SOAP kommunikáció közepébe, mint egy átjátszó- 
adó, és így ki tudjuk elemezni a SOAP forgalmat. A Network 
monitorhoz hasonlítható, csak ez nem passzívan hallgató- 
zik, hanem aktívan figyel egy porton, elkapja a kapcsolat- 
felvételi kérelmeket, és átjátssza őket a megadott címre, 
majd onnan vissza a választ. Tulajdonképpen egy olyan 
SOAP proxy, amellyel még ki is tudjuk elemezni a forgalmat. 
A program használatához tudnunk kell, hogy a SoapClient miu- 
tán letöltötte a wsdl állományt, akkor nem ugyanazon a címen 
kezdi el keresni a SOAP szolgáltatást, hanem a wsdl-ben kike- 
resi a service elemet, és azon belül a soap:address elem loca- 
tion attribútumában leírt címre küldi el a SOAP csomagot: 


:"Wsdl részlet 


service namez"fajlolvasoz 
port namez"FileManSoapPort" 
binding-"wsdlns:FileManSoapBinding"5 
csoap:address location-"http://csharp.dotnet.- 
hu/szappan/ 
4 fajlolvaso.wsdl" /5 
£/port2 


£/services 


Alapértelmezésben ez ugyanoda mutat, mint ahol a wsdl fájl la- 
kik, de ettől nyugodtan eltérhetünk. A tracer használatához ezt 
át kell írnunk arra a címre, ahol a tracer várni fogja a 
SOAP csomagokat. Például ugyanazon a gépen a 8080-as portra: 


http://csharp.dotnet.hu:8080/szappan/ 
b fajlolvaso.wsdl 


Ha így átírtuk a wsdl-t, akkor az eddigi ügyfélprogramok a 
fenti címre fognak postázni, azaz a nihilbe. Ez nem jó sen- 
kinek, jöjjön a tracer! 

Amikor elindítunk egy trészelést, a következő dialógussal 
találjuk szembe magunkat: 


31 
LTE ESZES ez ES ÉS et] 
Local port tt: EU 
TET BZE ez E SZ 
Destination host localhost 
Destination port: 80 
ÁGAT BEST 2E VÉSSEZTENE Tt EE üt] 

Ezert ] 


Megkérdezi, hogy melyik helyi TCP port-on várja a tracer a 
kéréseket. Ide nyilván azt írjuk be, amit a wsdl fájlba írtunk, 
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hisz itt fogják keresni az ügyfélprogramok a SOAP szervert. 
Az alsó részen állítjuk be a valódi SOAP szerver nevét és port- 
ját. Ide fogja átjátszani a fenti port-ra érkező kéréseket. 

A tracer-ben választhatunk a formázott és a nemformázott 
kimenetetek közül. A nemformázott olyan, mint amit a 
hexa editorokban láthatunk: a baloldalon hexában a bájtok, 
a jobboldalon a szöveges értelmezésük. 


MSSo3pT - (listening for localhost at port 8080, destination port 80]. 














A baloldali részen láthatóak azok az ügyfélgépek, amelyek 
forgalmaztak a tracer-en keresztül. A jobb felső ablakban a 
SOAP kérés látható, az alsóban pedig a SOAP válasz. 

Aki már elszokott a hexa editoroktól (például én) , annak ja- 
vaslom a formázott trace-t. File, New, Formatted Trace. 


F-g" standaloneznot 75 








"http://schamas.xmisoap.org/s0ap/encoding/" 
las xmisvap.org/s0ap/enyelope "2 








Az elrendezés ugyanaz, csak ebben az esetben az Internet 
Explorer-től megszokott formázásban láthatjuk a SOAP bo- 
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rítékokat. Érdemes a képet kicsit tanulmányozni, akár úgy, 
hogy elővéve a cikk előző részét azonosítani benne a külön- 
böző SOAP huncutságokat: a borítékot, ki milyen névtérben 
van, a válasz nevét, satöbbi. 


Amiről nem beszéltünk 

Mint említettem, az előző oldalakon felvázolt magasszintű 
SOAP API nem képes olyan típusok közvetítésére, amelyek 
nincsenek benne az XSD-ben. Azaz általunk írt osztályok, 
struktúrák esetén segítenünk kell a SOAP komponenseknek. 
Ehhez egyfelől át kell írnunk a wsdl típusleíró szekcióját, és 
az XSD szabványnak megfelelő formátumban leírni a komp- 
lex típusainkat. Másfelől írnunk kell egy Custom Type Map- 
pert, ami a legelső ábrán látható architektúrában le tudja 
kezelni az általunk használt összetett típusokat. Valójában 
ez nem bonyolult, egyszerűen implementálni kell a 
ISoapTypeMapper interfészt (VB Implements kulcsszó) , azaz 
megírni néhány szükséges metódust. Emellett a wsml fájl- 
ban is hivatkozni kell a Mapper objektumra. Részletek a 
Toolkit helpjében. 

Emellett levezényelhetjük a teljes SOAP kommunikációt mi 
magunk is, de erről majd a jövőben... 


Zárszó 

Ahogy a cikkben már többször beharangoztam, a következő 
részben a .NET Framework által szolgáltatott WebSzervizzel 
fogok foglalkozni, amely egy másféle SOAP implementáció. 
Addig is javaslom a példakódokat és a SOAP SDK-t letölte- 
ni, és kísérletezni vele. Nagyon szellemes példákat is adnak 
hozzá, érdemes azokat is kipróbálni. 


Írta és rendezte: Soczó Zsolt 
Zsolt.Soczo 2onetacademia.net 


A cikkben szereplő URL-ek: 


[1]: SOAP Toolkit 2.0 SP2 


http://download.microsoft.com/download/xml/soap/2.0/W98NT42KMe/EN-US/SoapToolkit20.exe 


[2]: SOAP Toolkit 2.0 SP2 Példák 


http://download.microsoft.com/download/xml/soap/2.0/W98NT42KMe/EN-US/SoapToolkit20Samples.exe 


[3]: Tesztalkalmazások 
http://technet.netacademia.net/download/xml 
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Hogyan tüntessük s 2vrus kv 
el nem használt ma 
fájljainkat? DUPLA 


Hogyan tüntessük el nem használt fájljainkat? "0 Atartalomindexelő katalógusfájljai, amelyek a kere- 
K: Tud valaki egy módszert, amivel biztonságosan, de haté- sések felgyorsítására készülnek 


konyan ki lehet pucolni a winnt-t, hogy a használaton kívüli 

áj án. 2 
fájlok eltűnjenek? E CEGSEKZÁK z 

V: A Windows 2000-ben a leghatékonyabb eszköz erre a I tissosssa] 








2]2d 











You can use Disk Cleanup to free up to 1.659.738 KB of disk 











feladatra a Windows-ba épített Lemez karbantartása (Disk EJ paceon (CL 

Cleanup) eszköz. Files to delete: 

Az eszközt a Programok (Programs) , Kellékek (Accessories), a SENNEEES I 

Rendszereszközök (System Tools) menü alatt találjuk Lemez BSZ bir élj 

a a é ó EiígT files 39.130 KB 

karbantartása vagy Disk Cleanup néven. A parancssorból EE áá KB] 
cleanmgr néven indítható. ; . fd  SSz TET Zea 
A program fő feladata a szükségtelen fájlok eltávolítása a € Description 
, merevlemezről, így a kisebb mérető lemezeken is értékes vshsser a jájsettáma ez enagteakseatskgy satteloszeásl 
helyet szabadíthat fel a hasznos programok vagy adatok ke eg ormtógése tos 
számára. Ehhez az egyébként - főleg a rendszerfájlok miatt - 

nem veszélytelen művelethez hatékony és biztonságos se- ViewFies 
gítséget nyújt - a rendszerfájlok letörlésére lehetőséget ————  —— — s — ÁZ 
sem ad. A program indítása után kiválaszthatjuk a takarí- Égéű 


tásra kijelölt merevlemezt. 





5 Több mint egy giga felszabadítható ezen az alig hasz- 





Select Drive 22 És 
B I nált gépen! 
Select the dííve you want to clean up. 
Drives: 
e (c r Ha nem a Windows 2000 telepített verzióját tartalmazó lemez 
Ja kerül kiválasztásra, akkor csak a kuka és a tartalomindexelő 





katalógusfájljai kiválaszthatóak. A Compress Old Files igen fi- 
gyelemreméltó tulajdonsága, hogy nem törléssel szabadít fel 











5 Lemezkiválasztás a Disk Cleanuppal helyet, hanem a régi fájlok (NTFS szintű) tömörítésével. Ki 
tudta eddig, hogy ilyen okos a Windows? Itt például az ötven 
Majd őrült reszelés kezdődik... napnál régebbi fájlokra mondunk ki tömörítési , ítéletet". 
HERAKOZÁRAB hi S 2 
SÁBTEAN OT El] keeeseptrseezz teste e eszes er jkósiszásbsz álta 
eeslátos ha ] Compress alter EH d days 
Scanning: Compress old files 
9 A felirat tanúsága szerint nemcsak helykiszámítás, Cancel 


hanem némi fájltömörítés is zajlik a háttérben 
5 Az ötven napnál régebbi fájlok tömörítése 
. . aminek során az eszköz feltárja a felszabadítható területe- 


ket. Takarítás a következő fájlok között lehetséges: A More Options fülön választhatunk a Windows összetevők 
"0 Temporary Setup fájlok (a telepítés után nincs szük- és a Telepített programok közötti takarításban is. Ha 
ség rájuk) ezekre a pontokra kattintunk, a Windows elindítja a Win- 
8 Letöltött programfájlok dows összetevők varázslót, illetve a Programok hozzáadá- 
"8 Temporary Internet fájlok, az Internet Explorer gyors- sa és eltávolítása eszközöket. 
tárolója Forrás : Netacademia Windows 2000 lista. 
"8 Régi chkdsk fájlok, a lemezellenőrzés során keletkezett í 
fájltöredékek Windows - Security Ki tekeri az üres floppymeghajtót? 
"8 Lomtár (Deleted Items) K: Mind a laptopomon, mind pedig a szerveren ugyanaz 
"0 Temporary (ideiglenes) fájlok, a Temp könyvtár tartalma az elmebaj lett úrrá, tekerik az ÜRES flopimeghajtót. Ez 
"8 Kapcsolat nélküli (Offline) fájlok, a hálózati kapcsolat mi? SP? Hotfix? Vírus? Tud erről valaki valamit? A dolog 
nélkül is használható hálózati fájlok egyértelműen nemrég kezdődött, de nincs meghatározó 
b Tömörített régi fájlok kiindulási pont, hogy mitől. 
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V: A tünetekből adódóan három alapvető okot lehet felté- 
telezni a lemez keresésére. A lemezt 

1. valamilyen program próbálja használni 

2. a Windows próbálja használni 

3. egy parancsikon (shortcut) miatt kell tekerni 

Mivel egyszerű kereséssel az esetek egyike is csak a szeren- 
csének köszönhetően oldható meg, célszerű valamilyen tu- 
dományos megoldás után nézni. 

Az első két probléma megoldására jól használható a 
Sysinternals cég Filemon eszköze, mely valós időben vizsgálja 
a fájlrendszer aktivitását. Képes az aktivitás naplózására az ol- 
vasás, írás, törlés, terhelések időbeni rögzítésére. 





(Elo Evt Seuh Dövee eb 
ETAGE ZITsT AT 
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5 A filemon működés közben 


Jelen problémára is a Filemon segített megoldást találni. A 
fenti 2. kategóriába sorolható problémát az okozta, hogy a 
lemezre történő másolás után a Windowsból kiléptek anél- 
kül, hogy a másoló ablakot bezárták volna, majd kivették a 
lemezt. A következő belépéskor a Windows azért kereste a 
lemezt, hogy megnyithassa az elmentett profilunk által 
diktált" ablakot. Egy floppy behelyezése után felugrik az 
A: ablak, s annak bezárásával megoldható a , probléma". 

A harmadik eset, mely nem használt - A: meghajtóra mu- 
tató - parancsikonokra vezethető vissza, a CHKLNKS.EXE 
eszközzel oldható meg. A programot a Windows Resource 
Kit tartalmazza. 


HOGYAN TÜNTESSÜK EL NEM HASZNÁLT FÁJLJAINKAT? 


ég Link Check Wizard 3 





"welcome to the Link Check Wizard 


Links are used to associate Desktop Shortcuts and Start Menu 
Items with an application or document. Manualy removing 
appácalions or documents can leave useless Link fles on your 
system 


The Link Check Wizard scans all of the Link. 
Files on your system. If the associated 

appiicalion or document for a Link is not found, 
the Wizard vil Est that Link File as a Dead Link 
giving you an option to remove it. 






5 A Link Check Wizard a levegőbe mutató parancsikonok 
gyilkosa 


A chklnks megvizsgálja a rendszer használt és nem létező 
fájlokra mutató linkjeit. A programban a nem szükséges lin- 
keket kijelölhetjük és eltávolíthatjuk. Az A: meghajtóra mu- 
tató linkeket is megtalálja és eltávolítja. 

Forrás : Netacademia Security Lista 


Windows 2000 - System 5 error occurred 

K: , System 5 error occurred" Honnan tudom kideríteni, hogy 
mit takar ez a hibaüzenet az Event View-erban? 

V: A Windows 2000 számmal jelzett hibaüzeneteinek jelen- 
tését a 


NET HELPMSG $hibaszám 


parancs segítségével kérdezhetjük le. A kérdésre a megol- 
dás tehát: 


NET HELPMSG 5 


A hiba jelentése: Access Denied, azaz hozzáférés (jogosult- 
sághiány miatt) megtagadva. 

A NET parancs a Windwos NT-ben és a Windows 2000-ben már " 
nem a DOS-ban megszokott egyszerű hálózatátirányítási funk- 
cióval bír, használata mindig egy segédparaméterrel történik. 
Forrás : Netacademia Windows 2000 Lista 


http://vilagokorseg.hu 









ÉS AKKOR AZT MONDTA, HOGY 
NEM TUD BÖNGÉSZNI OUTLOOK 
EXPRESSBŐL... 


MAJD LETIL- 
TOTTA A 
PROXYT ÉS 
FELHÁBORO- 
DOTT, HOGY 
NEM TUD IN- 
TERNETEZNI!! 













NE LÉGY MÁR ANNYIRA GONOSZ. 
VELED NEM FORDULT MÉG ELŐ, 
HOGY MONDTÁL VALAMI BAROM- 
SÁGOT, MAJD ZAVARODBAN EGY- 
RE NAGYOBB HÜLYESÉGEKBE BO. 
NYOLÓDTÁL BELE? 


VÉGÜL ARRA KENTE AZ 
EGÉSZET, HOGY KÉT 
HÉTTEL EZELŐTT VOLT 
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Megértő 
gépek 


A Csillagok háborújának 6 millió nyelvet beszélő protokolldro- 
idja, az űrszekerek univerzális fordítógépe, az űrodüszszeia lágy 
hangú, de engedetlen központi számítógépe és Asimov ember- 
szabású Daneelje, akit legfeljebb a szlengszavakkal lehetett za- 
varba hozni még mindig sci-fi. A természetes nyelvek feldolgo- 
zását fürkésző kutatók azonban rendületlenül dolgoznak a szin- 
te végtelennek tűnő távolság csökkentésén. Feladatuk nem 
könnyű, sokak szerint pedig egyenesen lehetetlen. Igaz ugyan, 
hogy Bill Clinton két éve nyilvánosan ígéretet tett arra, hogy a 
közeljövőben valós idejű fordítógépekkel rukkolnak elő, abban 
azonban egy kicsit sem vagyok biztos, hogy ezek a szó nemes 
értelmében vett fordításokat készítenek majd. 
De miben is áll a feladat nehézsége? Hiszen minden ember ké- 
" pes erre. Nem dramatizáljuk kicsit túl a feladat komplexitását? 
A természetes nyelvek elképesztően bonyolultak, ráadásul bizo- 
nyos értelemben önálló életet élnek. Számunkra ez kiváló kommu- 
nikációs eszköz, de a gépek (és főként a megvalósításukon fárado- 
zó kutatók, mémökök) számára maga a pokol. Ember legyen a tal- 
pán, aki képes megfigyelni, hogy mi zajlik le egy beszélgetés köz- 
ben az elméjében, merthogy erre más módszer egyelőre nem lé- 
tezik. Egy szöveg értelmezése nemcsak a mondatok szavainak 
egyszerű szótári elemzését jelenti. A többjelentésű szavak, a szö- 
vegkörnyezet, az átvitt értelmű megfogalmazások, a nyelvtani és 
szintaktika hibák felismerése stb. alaposan megnehezítik azt, ami 
amúgy is nehéz: a természetes nyelv formalizálását. 
Szánt. Ez most ige vagy egy főnév tárgyraggal? És ha ige, ak- 
kor jelen idejű, vagy múlt idejű, merthogy a jelentése ráadá- 
sul még ettől is függ. Utóbbi esetben, ha például angolra for- 
dítjuk, akkor a cselekvő nemét is jó lenne tudni. A kérdés el- 
döntése matematikai értelemben túl bonyolult ahhoz, hogy 
akár csak az érzékeltetésével is meg mernék itt próbálkozni. 
A Microsoft viszont úgy döntött, hogy vállalkozik rá. 1991- 
ben megalapította első három kutatócsoportját, melyeknek 
egyike azóta is a természetes nyelvek feldolgozásával (NLP 
- Natural Language Processing) foglalkozik. Létszáma mára 
már 30 fő fölé emelkedett, és 1997-ben létrehozták azt a 
több mint 100 főt számláló csoportot, amelynek az a felada- 
ta, hogy a kutatási eredmények termékekben is megtestesül- 
jenek. Az NLP csoport igazi különlegességnek számít, mert 
olyan általános megoldást próbál kifejleszteni, ami minden 
nyelvnél és alkalmazástípusnál felhasználható - olyanoknál 
is, amikről ma még nem is tudunk. A Microsoft nem először 
tűzi ki magának célul azt a jól bevált módszert, hogy min- 
dent saját fejlesztéssel, az alapoktól kiindulva épít fel. 
Az NLP rendszer alapját az elemzés (parsing) képezi, amely a 
gép számára értelmezhető formába önti a szöveg tartalmát. En- 
nek birtokában már viszonylag egyszerű információt keresni, 
fordítást készíteni vagy egy természetes nyelvi hatást keltő 
párbeszédet folytatni. Ezt segíti a MindNet névre keresztelt 
adatbázis, amelyet kifejezetten logikai képletek tárolására és 
keresésére fejlesztenek. A MindNet a precedenselvű feldolgozás 
területét képviseli, miszerint a számítógép a szöveges bemene- 
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tet korábbi információk figyelembevételével elemzi. Az adatbá- 
zist különféle dokumentumok előzetes vizsgálatának eredmé- 
nyeivel töltik fel. Ezek egyszerűsített gráfok, amelyek a monda- 
tokon belüli szavak szemantikai kapcsolatrendszerét térképezik 
fel. A módszer általánossága többek között abban rejlik, hogy 
a gráfokat előállító kód minden nyelvnél ugyanaz. Az NLP rend- 
szer tehát ezeket a logikai formulákat használja a szavak közöt- 
ti kapcsolatok egy nyelven belüli vagy nyelvek közötti keresé- 
sére. A szavak közötti tárolt kapcsolatok adják az alapot ahhoz, 
hogy egy természetes nyelven feltett kérdésre válaszolni lehes- 
sen. A MindNetet több szótárral, és a Microsoft Encarta encik- 
lopédiájával töltötték fel, hogy a megértés minél tökéletesebb 
legyen. A rendszer jelenleg a szavak közötti kapcsolatok 25 faj- 
tájának felismerésére képes (például tárgy, hely, idő). 

A természetes nyelvek feldolgozásának képessége utat nyit- 
hat például a valósidejű fordítógépek és a felhasználói igé- 
nyekhez alkalmazkodó, különféle információs forrásokon ala- 
puló összefoglalók készítéséhez. Erre bizony nagy szükségem 
lenne akkor, ha például egy 100 oldalas japán dokumentumot 
kellene egyik napról a másikra elolvasnom. Az alkalmazások 
skálájának csak az emberi képzelőerő szabhat határokat. 

És mikor lesz ebből valami? Bármilyen meglepő, a csoport 
eredményeit folyamatosan próbálják adaptálni a termékekhez. 
Egy profitból élő cégnél ez nem is működhet másként. A Mic- 
rosoft az NLP esetében hosszú távra rendezkedett be: a kuta- 
tókat a nagy cél elérésére nagy szabadsággal ruházták fel, a 
sFészeredményeket" pedig ügyesen beépítették a termékeikbe. 
A Microsoft Word-ben található helyesírásellenőrzőt 1997- 
től az NLP fejlesztések jóvoltából használhatjuk. Korábban 
ezt a feladatot egy másik cég terméke látta el. 

1999-ben az NLP csoport készítette el a Microsoft Encarta en- 
ciklopédia keresőmotorját. A felhasználók ebben már termé- 
szetes nyelven is megfogalmazhatják a kérdéseiket, amire ál- 
talában jobb választ kapnak, mintha a hagyományos módon, 
kulcsszavakból összeállított logikai lekérdezést használnának. 
Az NLP további fejlesztése magától értetődően ezeknek a prog- 
ramoknak a hatékonyságát is növeli majd. A közeli tervek között 
szerepel, hogy ezek az alkalmazások más nyelven is elkészülje- 
nek. A Microsoft ugyanis, globális vállalat révén, nagy hangsúlyt 
fektet arra, hogy a nem angol anyanyelvű felhasználók is minél 
jobban ki tudják használni a számítógépek adta lehetőségeket. 
Az NLP csoport az angol mellett jelenleg hat másik nyelvvel is 
foglalkozik. A gépi fordítás mindemellett jól összefogja a külön- 
féle nyelvekkel kapcsolatban végzett fejlesztéseket. 

Azt talán korai lenne állítani, hogy küszöbön áll egy újabb 
technológiai forradalom, de úgy tűnik, hogy a küszöb felé 
vezető út önmagában is nagyon gyümölcsöző. 

Aki pedig mindezzel elégedetlen lenne, az keresse fel az In- 
terneten Alice-t (http://www.alicebot.org), a 250 IO-val 
felprogramozott csevegő robotot, és öntse bitekbe bánatát! 


(Zacco) 
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b Szoftverrazzia 





Event Detail 
Date: 5/27701 EventID: 7001 
Time: 5:34:27 PM Source: Service Control Manager 
User NZA Type: Error 
Computer: VSNT01 Category: None 
Description: 


Nyomtatás HP JetAdmin , segítségével" 
Beszta János harca a nyomtatásért nem várt kiütéses 
győzelmet hozott a HP-nak! 


E nés 2 xi 





4 függő változó nem elég nagy a függőnek, 
Ellenőrizze a függő határozókat, 


9 


Hiba 401. 





IMS konfúzió 

Hívjon szakembert, aki még ezt sem tudja 
megoldani! A probléma egyébként az 
alábbi ábra tanúsága szerint nem is az 
IMS-ben, hanem a Message Transfer 
Agent táján keresendő. Vajon mire vár? 


Szoftverrazzia 

A következő városokba 
rendelünk szoftverrazziát 
novemberre: 
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The Microsoft Exchange Internet Mail Service service depends onthe A 
Microsoft Exchange Message Transfer Agent service which failed to 

start because of the following error: 

The operation completed successíully. 





Data: 6) Bytes C Words 





ge Transfer Agi 
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Szuper!! 

Pont jókor jöttem. . . 
csak csendben oda- 
surranok és már e- 
ém is a tech.nei 


csak tegye az 
asztalomra! Z 1 
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( más magazínját jú meszesák ogy pótólhatatlan veszteséget. 
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A NETACADEMIA INTERAKTÍV MIKULÁS KONFERENCIÁJÁRA 


2001. december 5. 


Regisztráció: fél 9-től. A laborok a szünetekben is nyitva lesznek. Megjelenésére feltétlenül számítunk! 





1. téma (kezdés: 9:00) 
LDAP, LDIF 


Előadó: Fóti Marcell 


Akkor tekintheti magát az Active Directory urának és parancsolójának, ha 
ugyanolyan bátran bele mer törölni a címtárba LDP.EXE-vel, mint amilyen bátran 
módosítgat a REGEDT32.EXE-vel a regisztrációs adatbázisban. Ehhez ,csak" 
alaposan kell ismerni... 





Interaktív tt 
LDIF és ADSI szkriptek 


Objektumok tömeges kezelése NOTEPAD , segítségével" 
e felhasználók létrehozása, mozgatása a hierarchiában 
e  csoporttagság átállítása 
e OU készítése és mozgatása stb. 








2. téma (kezdés: 11:00) 
Golyóálló 
webkiszolgálók 
Előadó: Fülöp Miklós 


Alapvető elméleti tudnivalók, mindennapi biztonsági eszközök 
e az operációs rendszer biztosítása 
e a nemkívánatos szolgáltatások letiltása 
e a hozzáférés korlátozása 
e a kérések szűrése - a naplók elemzése 





Interaktív tt 
IIS kézimunka 


Az IIS telepítése, konfigurálása — a biztonsági eszközök használata (hfnetchk, 
iislockd, urlscan, stb.) — a nem használt portok lezárása (IPSec policy) 








3. téma (kezdés: 14:00) 
RSA 


Előadó; Fóti Marcell 


Interaktív t-t 


Minden, amit tudni akarsz a nyílt kulcsú titkosításról, de nem mered megkérdezni 
e — Hogy működik? Mi a matekja? Hogyan használjuk a gyakorlatban? 
e — Biztos, hogy biztos? Mikorra várható az RSA összeomlása? 
e — A Microsoft Certificate Server szerepe 





Certificate Server telepítése, SSL megvalósítása IIS-en 








4. téma (kezdés: 16:00) 
Microsoft.NET 


emberközelben 
Előadó: Soczó Zsolt 


Mi újság a Matrixban? - CLR tanmese 
Ctt vagy JAVA--? - A MS-Sun boxmeccs 
Mi lesz veletek VB programozók? - A VB jelene és jövője 
Alkalmazás 
Puttony.NET - ASPt, az ígéret földje 





Interaktív t-t 
.NET programozás 








.NET programozási laborgyakorlatok Ct és VB.NET nyelven. Kicsiknek és 
nagyoknak, kezdőknek és haladóknak különböző összetettségű feladatok (Hello 
Világ, Webszervizek stb.) § 





" interactive (Computer Science) Olyan programokkal kapcsolatos kifejezés, melyek 
válaszolnak a felhasználók igényeire. A 5 NNETACADEMIA MIKULÁS KONFERENCIA például lehetővé 
teszi, hogy a helyszínen telepített számítógépes laborban s módon mindent kipróbáljunk! 
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Access-VB-SOL Advisor 

A/C Flyer 

Architectural Record 

Aviation Week 

Business 8. Commercial Aviation 

Business Security Advisor 

Business Week 

Design.Build 

Dr. Dobb"s Journal 

e-BUSINESS ADVISOR 

Electrical World 

ENR 

FileMaker Pro Advisor 

FoxPro Advisor 

Harvard Business Review 

Healthcare Informatics 
The Hollywood Reporter 
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Hospital Practice 
Infoconomist 

Information Week 

Internet Week 

Lotus Advisor 

MSDN Magazine 

Network Computing 
Network Magazine 

New England Journal of Medicine 
Overhaul 8. Maintenance 
Physician 8. Sportsmedicine 
Postgraduate Medicine 
Power 

tele.com 

Unicenter TNG Advisor 
Websphere Advisor 

World Aviation Directory 


Newsletters: 

Aviation Newsletters 

Energy 8 Business Newsletters 
New England Journal of Medicine N. 
Platts Newsletters 

UDI Newsletters 


Advisor Archival CD s: 
Access-VB-SOL Advisor 
Lotus Advisor 

Business Security Advisor 
e-Business Advisor 
FoxPro Advisor 

FileMaker Pro Advisor 
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! nov: 19.! nov. 12.) "növ:5.! nov.12.! Okt. ; 
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2152 "Implementing Windows 2000 Server and Professional 5 nap 125000 





[es Implementing Windows 2000 Network Infrastructure , 5 nap 125 000/ 

















12154 "Implementing Windows 2000 Directory Services 5 nap 125 0007 
1572 !Implementing, Administering Exchange 2000 5 nap 139000 9.! "dec.3.! nov.26.! dec.3.! nov.19.! 26. 
fi ij Í A d 
1561 ! Designing Windows 2000 Directory Services 3nap 95000 5 i, 8—— al KN a tune 
decs40.! ! jan. 7.1-dec.12.!) "jan.7. dec.10.! (. déceir. 
2159 ! Deploying and Managing ISA Server 2000 2nap 790000 láz tl Í vb ll) ESEM ú 7T 
ovábbi tanfolyamokról és időpontokró djön szervezőinkné s észletes tájékoztatót küldünk 
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